Xref: utzoo comp.unix.internals:2524 comp.unix.admin:1571 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!ox.com!math.fu-berlin.de!fauern!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: comp.unix.internals,comp.unix.admin Subject: Re: Unix security additions Message-ID: <1092@mwtech.UUCP> Date: 11 Apr 91 15:37:46 GMT References: <39950@cup.portal.com> <1991Mar14.230944.9184@eci386.uucp> <1991Mar22.024124.3238@ec Reply-To: martin@mwtech.UUCP (Martin Weitzel) Organization: MIKROS Systemware, Darmstadt/W-Germany Lines: 118 In article <19183@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: jfh> In article <1090@mwtech.UUCP> martin@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@mwtech.UUCP, voice: 49-(0)6151-6 56 83