Re: [PATCH][RFC] Simple tamper-proof device filesystem.

On Fri, Jan 11, 2008 at 11:05:07PM +0900, Tetsuo Handa wrote:
Not only mknod() but also rename()/unlink()/link()/mount(bind) etc. that may
cause filename/attribute mismatching.

How can the daemon know whether the request is trying to manipulate nodes
in /dev directory or not?
If "mount --bind /dev/ /var/dir/" is used, the daemon must check
filename/attribute pair when mknod("/var/dir/null") is requested
because permitting the request will modify /dev state.
If "mount --bind /dev/ /var/dir/" is not used, the daemon must not check
filename/attribute pair when mknod("/var/dir/null") is requested
because permitting the request will not modify /dev state.



What does the daemon do? It receives requests from the LD_PRELOAD library
using UNIX domain socket and checks filename/attribute pair and issue
mknodat()/renameat()/unlinkat()/linkat() etc. when the combination is appropriate?

What does the LD_PRELOAD library do? It intercepts all pathname related syscalls
(except open()) and solve directory component and determine whether the request is
trying to manipulate nodes in /dev direcrtory and forward request to the daemon
using UNIX domain socket?

"Make the daemon and the LD_PRELOAD library bug-and-race free and
develop the MAC policy for the daemon and the LD_PRELOAD library"
and "Make this filesystem bug-and-race free". Which one is easier?

I think a good question is:

What kind of idiot wrote a program that thinks it is allowed to go
messing with the contents of /dev? There simply can't be a good reason
for an application to do that. Device nodes should match up with
devices, so as long as the device nodes exist for all your devices, then
everything should just work and no one should ever have a reason to go
changing things for any reason.

Perhaps the real solution is a preload library that blocks the idiotic
program from touching anything in /dev with anything other than
open/close/read/write.

Of course it could also help to simply tell people what this stupid
program is actually doing and why it should be allowed to mess in places
it doesn't belong.

--
Len Sorensen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH][RFC] Simple tamper-proof device filesystem.
    ... If the process is in the chroot() but the daemon is not in the chroot, ... How can the daemon know whether the request is trying to manipulate nodes ... using UNIX domain socket and checks filename/attribute pair and issue ...
    (Linux-Kernel)
  • RE: LDAP : Who Am I extended operation
    ... daemon: activity on 1 descriptors ... Message Type: Extended Request ... Mesage Length: 27 ... So the concrete LDAP data is: ...
    (microsoft.public.win32.programmer.networks)
  • Re: [RFC] Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
    ... daemon asking it to try and umount the select mount after which the daemon ... completion of the original ioctl expire request. ... The Generic Netlink interface won't allow this because only one concurrent ...
    (Linux-Kernel)
  • Re[2]: nscd for freebsd
    ... If you are strict NSS, you might be able to use the ... TL> thread per request. ... TL> I think you would need to have someone work on the actual libc ... TL> code to go with the daemon, as a proof of implementation, but I ...
    (freebsd-hackers)
  • Re: creating demon programs
    ... >> Can i ask for a simple C code creating a demon? ... you might consult with the devil. ... *When a request is made, ... I've never written a daemon, but this is what I remember ...
    (comp.os.linux.questions)