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

[Lennart Sorensen]

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/