Getting rid of the root account

[John F. Haugh II]

In article <4499 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>In article <16659 at rpp386.Dallas.TX.US>, jfh at rpp386.Dallas.TX.US (John F. Haugh II) writes:
>> Consider for a moment a `mount' program...
>
>> The alternative is to grant the mount program `MOUNT' privilege
>> _and_ use permission bits....
>
>A perfect example of why this is a red herring.

No, this is a perfect example of a trustable system.  Least privilege
is a _requirement_ for trusted computing systems.  It isn't something
you get to wave off as being a `red herring'.  Minds far better than
yours or mine have MANDATED that this is going to be the way it is
going to be.

	'The TCB modules shall be designed such that the principle
	 of least privilege is enforced.' -- TCSEC 3.2.3.1.1

>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.

Yes.  Now that you can mount something, what are you going to mount?

	'The TCB shall support the assignment of minimum and
	 maximum security levels to all attached physical devices.'
					-- TCSEC 3.2.1.3.4

Now that you have this floppy containing your password-free su,
who are you going to convince to mount it on the only trusted
floppy drive in the system?

Your assumption is that you will be able to obtain, through some
machinations an arbitrary privilege.  A system with this as a flaw is
open to more direct attacks than having bogus file systems mounted.

>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'.

You assume a trusted system is going to trust any data being imported?

>So why be complex when you can be simple?

Because simple does not work in this case.

It is not sufficient to state that a system performs its claimed purpose,
you must demonstrate that the system is designed in such a fashion that
it degrades gracefully.  Obtaining some individual privilege should not
grant every privilege.  The current UNIX idiom requires one to only know
a single critical flaw.  A layered privilege approach requires you to
know a flaw which will grant you the entire set of privileges required
to perform a task.  Even then the system may not trust YOU to execute
the process which you have constructed.  [ Please reference VAX/VMS
which includes the concept of an operator console, something which UNIX
does not presently support ]

Please, before anyone else wants to waste time responding about their
ideas regarding security, read a bit about what people who have already
defined security have to say.  The objections Peter has raised display
a severe lack of understanding about the current state of the art in
trusted systems designs.
-- 
John F. Haugh II                        +-Button of the Week Club:-------------
VoiceNet: (512) 832-8832   Data: -8835  | "AIX is a three letter word,
InterNet: jfh at rpp386.Cactus.Org         |  and it's BLUE."
UucpNet : <backbone>!bigtex!rpp386!jfh  +--------------------------------------