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