Hello.

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

quoted text
> 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 .

quoted text
> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html