Unix security additions

[Martin Weitzel]

In article <19183 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F Haugh II) writes:
jfh> In article <1090 at mwtech.UUCP> martin at mwtech.UUCP (I) wrote:

mw>> Well, I know this complaint that UNIX isn't secure because there is
mw>> one person who can read the files of all others ... but what if there
mw>> were no such privilege?
mw>> 
mw>> 	- how should checks of the filesystem integrity, backups and
mw>> 	  restores be done if not some few programs could acces the raw
mw>> 	  information of the disk?

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

That was not quite my point (maybe it was badly stated). My first remark
should alert the reader that every computer system will at least contain
*some* programs that are able to read every user's data. (The difference
under UNIX is that *any* program can be used for it if it is used from
a privileged account.)

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

jfh> At some point in time you have to trust the people you've hired to do
jfh> their jobs.

Wait a minute: Given the scenario that in a (badly configured) UNIX system
I have to give a privilegded account to those people who have to care for
backups. Now I complain: This is really bad - I don't trust these people and
fear they will use their privilegded account to sneak into other user's files.
Under this circumstances, would it be wise to trust the same people that
they don't take the backup tapes and read them anywhere else? The counter
argument may be that it is much easier to try a "cat someone-elses-file"
than to carry a tape to another system. But then the solution with some
extra accounts that can only be used for certain privileged activities
(as described later) will also suffice, even if there are some loopholes,
as long as a high enough a barrier is placed so that noone can simply
"cat" someone elses files from the backup account.

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

In general - as you may have noted - I sympathisize with the idea to split
the rights to do things (change user privileges, do backups, etc.) to
several accounts.

My claim still is that this can be done without changing the kernel, and
that the added security you win *if* you make enhancements to the kernel
is far less than the chance that some people you hired to do their jobs
CAN'T be trusted.

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

jfh> Sure, this is one approach.  Now insure that I can't take my "change any
jfh> user account" authority and change my login shell to be /bin/sh, or the
jfh> "execute any command" login shell.  You have to insure that no collection
jfh> of privileges that a user might have can be combined in some fashion to
jfh> grant some other privilege they did not already possess.  By giving them
jfh> "all" privilege and sticking them in some particular program, you have to
jfh> write that program very carefully.  You must then do the same for every
jfh> other program they might execute. It is far easier to divide the
jfh> privileges in one place, and let the kernel manage it, rather than
jfh> trying to get it right in every single program the administrators might
jfh> execute.

This is a well taken argument. In general I support the idea to centralize
important things in a few places instead of spreading them throughout the
system. If I bring up a counter argument now, I don't do so to "win the
battle" in this discussion, it's only one point I want to remind the
readers of this thread:

If a really serious security bug should become known (and which product
never had any security bugs?) I much prefer to be able to correct it by
changing some access-rights, rewriting some shell procedures or similar.
As a last resort, I could even rewrite some program (for backups, filesystem
checks or whatever) if I don't have the source code and it exposes some
serious security flaw. (Most preferrably I would replace such a program
with a trusted PD-version which comes with source.) But if there is
a bug in the kernal's security mechanisms, I'm rather helpless and will
have to wait for a fix from the one who has the kernal source for my
system. (And: Recall how long it lasted until ISC recently could be
made to correct the "witable u-area bug" in their product!)

Summary: I think I could be quite happy with the security mechanisms of
the V7 kernal, combined with a new login which stores passwords in a file
with no read-acces for the public, a secure "mkdir" implemented as system
call and preferably the source (or PD-replacements) for all the programs
that are run with EUID == 0, so that I can cure all deficiencies as soon as
they become known. Add to this a setup as described some pragraphes above
with different accounts for certain privileged activities as backups etc.
(if required by the operating environment) and I think I would have a
rather secure system and I would surely NOT demand for changes in the
kernal.
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83