On Thu Nov 13 2008 at 12:01:27 -0500, Thor Lancelot Simon wrote: > The security model is intended to protect (some components of) the system > from persistent compromise even by a misbehaving process *with euid 0*. > > The original design prohibited access to any partition "containing a > mounted filesystem". Effectively, partitions were treated as exclusively > owned by the first thing to open them. The issues of overlapping > partitions, non-filesystem in-kernel users of devices, and access to > the partition table itself were basically overlooked (one or two ports > disksubrs tried to do the right thing, but they all got it wrong somehow). > > A simple fix would be to add a list of partitions -- or even entire disks -- > that _may_ be later opened, which could only be altered at securelevel 0. > This interacts with wedges in some ways that are not entirely clear to me > at first glance, though. The more comprehensive fix would probably be > code like what Elad offered, to actually detect which partitions overlap > one another and forbid such access. Then the list would not be necessary. > > Now, if you have a bug in a kernel filesystem, you lose no matter what we > do here, because it is running in kernel mode and can just ignore the > sort of protections I describe above. One really nice thing about user > space filesystems is that that's not so -- even if they run as root -- > except for what is essentially a disksubr bug allowing them to get access > to all raw devices if they can get access to any. Uh, so let me try to see if I understood you now. Are you suggesting you're worried that a process with root priviledges can compromise system security? I do not recommend running a file server as root, *especially not* when running against an untrusted image. Or do people run a http or name server as root also? In other words, the security problem for the userspace file system server scenario does not exist.