[782] in linux-security and linux-alert archive
Re: [linux-security] standard users,groups,perms?
daemon@ATHENA.MIT.EDU (Jesse Pollard)
Tue Jun 11 11:51:02 1996
Date: Tue, 11 Jun 1996 10:21:12 -0500
From: Jesse Pollard <pollard@msrcnavo.navy.mil>
To: linux-security@tarsier.cv.nrao.edu
In-Reply-To: Mail from 'shaggenbunsenburner <shagboy@thecia.net>'
dated: Thu, 6 Jun 1996 17:47:28 -0400 (EDT)
From: shaggenbunsenburner <shagboy@thecia.net>
>> > Recently, at a site whose administrator is in our local SAGE chapter,
>> > someone's helper edited the /etc/password file and accidentally altered
>> > the super-user password. The /etc/password file was owned by root. It
>> > couldn't be fixed without resorting to booting a stand-alone system in
>> > a memory disk from the installation media. That took a while - and an
>> > appeal to the mailing list - to come up with. Needless.
>>
>> What is the point ? do not let someone's helpers cousin's neighbors edit
>> your password file :-)
>
>hahaha :) My question is, how would spreading the superuser privilege
>have avoided this disaster?
The user having partial root privileges would not have been able to
prevent root from logging in. This has happened to me several times
(usually an utility bug of my own creation). I permit a small list
of users the ability to create user logins. These users cannot modify
any uid less than 99, and cannot modify the /etc/password file at all.
These users access the NIS maps which are NOT part of the /etc/passwd
file. This has worked very well for about 2000 users, across 10 SGI
servers and workstations.
Root does own the files. The edit functions are implemented via a setuid
program that only permits the edit functions on internally defined files
(the NIS password and group files). The functions also create backup files,
and a single level undo capability.
As far as other root functions - consider Cray UNICOS (yeah I know, you cant
get one for the house). This system support multi-level security and is one
of the most security-aware systems I know (out of HP/UX, Sun Compartmented
mode workstation, and Trusted IRIX). On this system, root is just a user.
No special priveleges other than file ownership. Even then the files cannot
be modified by root unless
1. proper compartment (similar to a group ID, but is separate)
2. proper level (no comparison available)
3. The file must not have security flags that prevent modification
(No, root cannot modify these flags).
Security is controlled by a security administrator (secadm). In this sense it
is like root, but does not own any of the system files (security configuration
files excluded). In addition - if secadm attempts to modify restricted files,
the login must satisfy items 1,2 and 3.
It IS possible for secadm to alter item 3. At this point UNIX security
comes into play. It is not possible for file modification to be done without
also becoming root. It is even necessary for root to grant the secadm the
privilege (usually by the normal group access) to read the security logs.
Security levels (item 2) provide protection by controlling access to the
various files by:
level used for example
syshigh always to be trusted shadow password file
15
. user files at various levels
.
0
syslow required files and programs to be /etc/passwd file
protected passwd, login ...
These levels have the following restriction:
if the level of a file is equal to or less than that of the process
attempting to READ it then use UNIX security for access control.
if the level of a file is equal to that of the process attempting to
WRITE it then use UNIX security for access control.
if the level of a file is higher than that of the process then access
is denied unless the security flags assigned to the process permit
access.
A process gains security flags by executing an image marked syslow, with
the necessary security flags. A sample of this is the password program
that must gain write access to the shadow password file.
There are no processes or users that can get the "syshigh" or "syslow" levels.
These are outside permitted active processes and only exist on disk. Since
all processes must then be between 0-15, access to system files is denied.
Yes, this does make system updates difficult. But - like most sites, these
rules are not completely enforced (when they are the system is called "Trusted"
UNICOS). The levels are present, violations are logged, but not prevented from
those logins with security override flags enabled. Of course, that can make
these logins equivalent to root, even so - they are not quite as powerful as
normal root logins.
In "Trusted" UNICOS, system and security updates can only be done at single
user level (no networks, no users other than the now all powerful root...)
Even having the security administrators password does not get root. A lot
of damage CAN be done, but it requires secadm, root, daemon, ... passwords
to get them, and although secadm can change these passwords, the system starts
to shut itself down when security violations occur too frequently (3 login
failures in a row, within a minute, disable the account - even root).
It is this layering of security that protects the system.
So much for my rambling. This is only an outline (doesn't get into
access control lists) and is incomplete, but does show some of the "spreading"
around of "root" privileges.
Jesse Pollard
pollard@msrcnavo.navy.mil
