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.

MNT_RDONLY is enforced by the underlying filesystem, so twiddling it in a
nullfs layer wouldn't help. Besides the fact that nullfs enforces
MNT_RDONLY from the underlying layer. :-)

MNT_RDONLY	/* read only filesystem */    
MNT_SYNCHRONOUS	/* file system written synchronously */   
MNT_NOEXEC	/* can't exec from filesystem */   
MNT_NOSUID	/* don't honor setuid bits on fs */ 
MNT_NODEV	/* don't interpret special files */   
MNT_UNION	/* union with underlying filesystem */   
MNT_ASYNC	/* file system written asynchronously */   
MNT_NOCOREDUMP	/* don't write core dumps to this FS */
MNT_NOATIME	/* Never update access times in fs */ 
MNT_NODEVMTIME	/* Never update mod times for devs */ 
MNT_SYMPERM	/* recognize symlink permission */    
MNT_EXRDONLY	/* exported read only */    
MNT_EXPORTED	/* file system is exported */   
MNT_DEFEXPORTED	/* exported to the world */   
MNT_EXPORTANON	/* use anon uid mapping for everyone */ 
MNT_EXKERB	/* exported with Kerberos uid mapping */  
MNT_EXNORESPORT	/* don't enforce reserved ports (NFS) */  
MNT_EXPUBLIC	/* public export (WebNFS) */    
MNT_LOCAL	/* filesystem is stored locally */   
MNT_QUOTA	/* quotas are enabled on filesystem */  
MNT_ROOTFS	/* identifies the root filesystem */   
MNT_UPDATE	/* not a real mount, just an update */
MNT_DELEXPORT	/* delete export host lists */   
MNT_RELOAD	/* reload filesystem data */    
MNT_FORCE	/* force unmount or readonly change */  
MNT_MWAIT	/* waiting for unmount to finish */  
MNT_UNMOUNT	/* unmount in progress */    
MNT_WANTRDWR	/* upgrade to read/write requested */   

A cracker could leave a nullfs which doesn't enforce NOSUID and NOEXEC
around after a break in, with the idea of being able to come back. But
this nullfs will show up in df, mount, etc, and in general be easy to
spot. If I were breaking into a system, I'd just crack login, init, ps,
cksum, and friends. :-)

If there is a gap in this reasoning, please point it out. I'm not seeing
it. :-)

Take care,

Bill