Unix security additions

[John F Haugh II]

In article <1090 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>Well, I know this complaint that UNIX isn't secure because there is
>one person who can read the files of all others ... but what if there
>were no such privilege?
>
>	- how should checks of the filesystem integrity, backups and
>	  restores be done if not some few programs could acces the raw
>	  information of the disk?

There are separate privileges for such things as determining file system
integrity, making backups, restoring files, etc.  For example, someone
in the "system administrator" role would be able to take backups and
perform restores.  There would be a separate mechanism for ensuring
system integrity, since a system which is in an unknown state shouldn't
be used anyhow and there is a difference between "repair" and
"maintenance" activities.

>If their exists a privileged account for the above mentioned activities
>(and name the OS on which there is no such account) then the door is open
>for installing any program you whish which does anything you whish with
>the data on the disk! Furthermore: If there is a person who can do backups
>on physically removable media, even if this person has not the privilege
>to read all the users data, how do you control what he or she does with
>the backups *after* removing the media?

At some point in time you have to trust the people you've hired to do
their jobs.  The point of slicing root privileges up into little pieces
is to make it so you can control what "their job" is.  For example, if
the "administrator" can create any unprivileged account, but only the
"security administrator" can create privileged ones, you can't go from
"administrator" to "privileged user".  Likewise, if you can only restore
files that were backed up using the special utilities, you can't just
put any program you want on the system.  It would have to have been
backed up with whatever enhanced privilege you are trying to restore it
with.  So you can't go from "random tape" to "privileged application"
either.

>Again, name the OS on which the things I described here are not possible.
>I'm not interested in hearing that they are purely more difficult, e.g.
>because there is no "superuser account" and special rights like accessing
>the raw disk is only granted to some few programs.

There are quite a few.  I suggest you read the "Evaluated Products List"
from the NCSC for a sampling of them.

>                                                    You can have this on
>UNIX too by simply creating some few new logins with UID 0 but the
>mentioned special programs (backup/restore, filesystem check, etc.)
>as "login shell". The "real" super user account must only be known for
>for extremly few activities, like installing new software and configuring
>the kernal.

Sure, this is one approach.  Now insure that I can't take my "change any
user account" authority and change my login shell to be /bin/sh, or the
"execute any command" login shell.  You have to insure that no collection
of privileges that a user might have can be combined in some fashion to
grant some other privilege they did not already possess.  By giving them
"all" privilege and sticking them in some particular program, you have to
write that program very carefully.  You must then do the same for every
other program they might execute.  It is far easier to divide the
privileges in one place, and let the kernel manage it, rather than
trying to get it right in every single program the administrators might
execute.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) |  Domain: jfh at rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."