On Mar 9, 2010, at 4:45 PM, Thor Lancelot Simon wrote:

quoted text
> On Tue, Mar 09, 2010 at 02:58:43PM -0500, Steven Bellovin wrote:
>> 
>> On Mar 9, 2010, at 2:55 PM, Thor Lancelot Simon wrote:
>> 
>>> 
>>> That's a matter for the kernel to decide -- not one for some userspace
>>> program which could be tampered with by any process running with euid 0.
>>> 
>>> At least, that is how I would strongly prefer it to be.
>> 
>> But what's to stop someone from mounting a new file system over /bin?
>> Or are you talking about secure_level 2?
> 
> I'm talking about trying to build policies which provide some of the
> guarantees we only provide at securelevel 2 now, but allow more flexibility
> to do things the administrator's decided ahead of time the system should
> be allowed to do.
> 
> Doing this right is not trivial (it may require a signature binding the
> contents of a medium to its UUID, etc.) but it's certainly not impossible
> either.
> 
> Causing all binding of names to devices to run forcibly through a userspace
> daemon *will* make such enhancements impossible.  That would suck.

I think that Joerg's proposal doesn't prevent you from doing what you want, though I don't think it helps, either.  He suggested that /dev/uuid and /dev/label just have symlinks to the usual device file, so no user-level daemons would be involved.  Those who have your security needs will mount on /dev/usualstuff; those who have topologically confused configurations would use /dev/label/whatever.  Many folks will mix and match -- a typical laptop, with only one hard drive, could have / on /dev/usual, while USB sticks and external hard drives would be referenced via the /dev/label symlink.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb