On Thu, Mar 11, 1999 at 05:03:59PM -0800, Bill Studenmund wrote:
> On Thu, 11 Mar 1999, Thor Lancelot Simon wrote:
> 
> > On Thu, Mar 11, 1999 at 03:11:59PM -0800, Bill Studenmund wrote:
> >  
> > > I think that's a bad idea. Checking each op will be expensive, given that
> > > flag changes are rare. Also, there's the problem that I think the idea of
> > > a root nullfs mount which has fewer restrictions than the layer on which
> > > it's loaded is reasonable (If root wants to hang him/herself, ok :-)
> > 
> > I do not.
> > 
> > Limiting how much damage root can do is *precisely the purpose* of some of
> > the mount flags we're talking about, at least the way I see it.
> 
> I'm confused. I'm enclosing below a list of all the mountflags we support. 
> Given how I ripped the flags out of sys/sys/mount.h, there are both
> persistent mount bits (NOEXEC, NOSUID, etc) and mount command bits
> (UPDATE, DELEXPORT, etc.) in this list.
> 
> I do not see any of them whose removal due to a root mount via an
> overlapping fs would compromise system security. Yes, a lot of these flags
> are there to keep users out of trouble, like the NOSUID and NOEXEC. But if
> you have a root process doing this, you've already lost. NOSUID doesn't
> matter as the intruder's already root. :-) And noexec doesn't matter as
> root can easily cp the file somewhere else.

NODEV does.  Consider a carefully-constructed chroot jail, at securelevel
< 2.  Devices for which there are no nodes in the jail can't be tampered
with (in theory).

Thor