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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080111144656.GL2310@csclub.uwaterloo.ca>
Date:	Fri, 11 Jan 2008 09:46:56 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	indan@....nu, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, w@....eu, serue@...ibm.com
Subject: 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/