On Mar 9, 2010, at 4:45 PM, Thor Lancelot Simon wrote:
> 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
