linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: indan@nul.nu, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, w@1wt.eu, serue@us.ibm.com
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.
Date: Fri, 11 Jan 2008 09:46:56 -0500	[thread overview]
Message-ID: <20080111144656.GL2310@csclub.uwaterloo.ca> (raw)
In-Reply-To: <200801112305.BII64642.tHOJSMLVQFFOOF@I-love.SAKURA.ne.jp>

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

  reply	other threads:[~2008-01-11 14:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-23 14:44 [PATCH][RFC] Simple tamper-proof device filesystem Tetsuo Handa
2007-12-31 20:02 ` Serge E. Hallyn
2008-01-01  2:16   ` Tetsuo Handa
2008-01-06  6:20     ` Tetsuo Handa
2008-01-06  6:26       ` Willy Tarreau
2008-01-06  7:36         ` Tetsuo Handa
2008-01-06  7:45           ` Willy Tarreau
2008-01-06 15:20           ` Tetsuo Handa
2008-01-07 20:37             ` Indan Zupancic
2008-01-08 13:50               ` Tetsuo Handa
2008-01-08 15:47                 ` Indan Zupancic
2008-01-09  4:39                   ` Tetsuo Handa
2008-01-09 13:59                     ` Indan Zupancic
2008-01-09 23:08                       ` Serge E. Hallyn
2008-01-10  1:06                         ` Indan Zupancic
2008-01-10  4:57                       ` Tetsuo Handa
2008-01-10 23:05                         ` Indan Zupancic
2008-01-11  8:46                           ` Tetsuo Handa
2008-01-11 12:22                             ` Indan Zupancic
2008-01-11 14:05                               ` Tetsuo Handa
2008-01-11 14:46                                 ` Lennart Sorensen [this message]
2008-01-07 17:09       ` Valdis.Kletnieks
2008-01-08 13:50         ` Tetsuo Handa
2008-01-09  5:04           ` Valdis.Kletnieks
2008-01-09  6:26             ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080111144656.GL2310@csclub.uwaterloo.ca \
    --to=lsorense@csclub.uwaterloo.ca \
    --cc=indan@nul.nu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=serue@us.ibm.com \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).