linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Valdis.Kletnieks@vt.edu
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	serue@us.ibm.com
Subject: Re: [PATCH][RFC] Simple tamper-proof device filesystem.
Date: Wed, 09 Jan 2008 15:26:31 +0900	[thread overview]
Message-ID: <200801090626.m096QWKl016866@www262.sakura.ne.jp> (raw)
In-Reply-To: <10946.1199855042@turing-police.cc.vt.edu>

Hello.

Valdis.Kletnieks@vt.edu wrote:
> Good summary - probably should add that to the patch, drop it into
> Documentation/syaoran-config.txt or similar...
I see.

> Modification while reading *is* an issue, but can probably be worked around
> with some clever locking.  The race condition I was thinking of was if you
> had the mount and the policy load be 2 separate events, you could see:
> 
> (a) issue mount request
>                         (b) do something malicious in /dev while..
> (c) load the policy that would have prevented (b).
> 
> This is partly why SELinux has init load the policy *very* early on, before
> any other userspace have had a chance to run and do things that would have
> been prevented by policy.
So, you suggested to load policy before mount() request so that
this filesystem can prevent attackers from doing something malicious
by minimizing (i.e. implement as non-blocking operation) the latency
between the userland process's call of mount() and the nodes become visible
to userland process.

I didn't take such cases into account.
My assumed usage of this filesystem is that run a script with

 #!/bin/sh
 mount -t syaoran -o accept=/etc/ccs/syaoran.conf none /dev
 exec /sbin/init "$@"

by passing "init=/path/to/this/script" to the kernel command line
so that /sbin/init can create /dev/initlog on this filesystem.
If you mount this filesystem after /sbin/init starts,
it will shadow /dev/initctl opened by /sbin/init .

> Which basically ends up meaning that anybody who can trick the mount into
> happening can reset the permitted list and create (for example) a mode 666
> entry for a hard drive, and go scribbling around at will.  Note that you
> don't seem to do any sanity checking on the path (for instance, that each
> component is owned by root, and not world-writable) - so anybody who finds
> a way to get the mount to happen can supply their own list in /home/joeuser/blat
> or /tmp/surprise-mount-list  or wherever.
I assume that being able to reach this location means the caller of mount() is root.
But, the patches to allow mount() by non-root is in progress? http://lkml.org/lkml/2008/1/8/131
May be I should add some sanity checking on the path.

Thank you.

      reply	other threads:[~2008-01-09  6:26 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
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 [this message]

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=200801090626.m096QWKl016866@www262.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serue@us.ibm.com \
    /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).