Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: Getting rid of the root account
Message-ID: <1566@mcgill-vision.UUCP>
Date: 22 Jun 89 05:38:54 GMT
References: <127@orchid.warwick.ac.uk> <16659@rpp386.Dallas.TX.US> <4499@ficc.uu.net>
Organization: McGill University, Montreal
Lines: 28

In article <4499@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
> In article <16659@rpp386.Dallas.TX.US>, jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes:
>> The alternative is to grant the mount program `MOUNT' privilege
>> _and_ use permission bits....

> So, you're saying that if you break that 'mount' program all you've
> broken is protecting the 'MOUNT' privilege, and root is still secure.

> But as soon as you get MOUNT privilege you can mount a file system
> containing a program with any other privilege you want... and you
> have the keys to the kingdom again. ROOT lives... it's just called
> 'MOUNT'.

Ever hear of "nosuid"?  If you're going to shatter the current single
privilege bit [yes, I know it's not stored that way] into many, there
will be two mount privileges, of which one grants permission to mount a
filesystem and the other grants permission to mount a filesystem in
such a way that the kernel (or filesystem handler, or whatever)
believes the privilege bits on it.  The second one *is* the keys to the
kingdom, as you point out - but /etc/mount doesn't have it: all
/etc/mount grants to a nonprivileged user is the first one.  In order
to do the second type of mount, you have to have acquired the
corresponding privilege bit from somewhere else.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu