Industrial Technology Institute
Ann Arbor, MI.
scs@iti.org
Abstract
A significant number of system break-ins are caused by incautious use of the root account. Other times an operator or new administrator inadvertently destroys sensitive system setups while using the root account for some completely unrelated purpose. Both of these have their root cause (pun intended) in UNIXs inability to grant privileges greater than ordinary user accounts without granting total access.
While there is no general solution to the problem, it can be mitigated by reducing the number of subsystems which require root access. This requires either removing the subsystem (not usually acceptable) or modifying it in such a way that a normal user account can administer it. We have had good luck with the latter, successfully administering news and uucp without using root except for creating accounts.
Along the way we've fallen into a few holes and established a few rules for keeping things running properly. We also have some suggestions for present systems designers.
Using non-root accounts to administer such subsystems
as news may have some additional benefits. In many situations management may be unwilling to have any fraction of
administrative time devoted to such "frivolous" pursuits.
Or they may allow it, but put it at such a low priority that
it effectively is never done. Using a non-root account
enables one to hand off responsibility to some highly
motivated third party who will do the administration on his
or her own time without giving that third party special
privileges.
To date we have fully implemented two subsystems on
which we can do rootless administration. The first of
these, the network news, is described in some detail. The
second, uucp, was significantly easier and is only briefly
described.
We have successfully administered both Bnews 2.11.14
[1]
and Cnews[2]
without using root.
This turned out to be surprisingly easy;
in retrospect we were fortunate in choosing news
as the first subsystem to do this with.
A standard installation of Bnews (and later Cnews) was
done. A new user account, news, was installed on the system. The home directory for this system was installed as
/usr/lib/news.
It was not judged sufficient that the news account simply be able to maintain the system; we wanted it to be able
to apply and install patches, debug systems, etc. Thus the
first step was to find all the files needed by news and make
sure they were writable by news.
We did not desire that news be able to install files in
such sensitive directories as /bin, etc. This would have
opened up the entire system to any errors or malice by the
netnews administrator. Instead we decided that initial
installation must be done by root, but all files installed
would be owned by news.
News was installed (actually re-installed, since we
were already running news) and we began. Immediately we ran
into problems.
Shell scripts run by cron [3]
tend to create files
owned by root. The news user was not able to modify these
files, making administration difficult. We considered a
number of approaches to deal with this, and actually implemented two of them. Both worked, but the second was definitely the better method.
We considered and rejected modifying all the news
scripts to explicitly set file ownerships, groups, and permissions. This would permit cron to run as root while not
causing problems with news administering news. The modified
scripts would be owned by news, letting the admin modify the
scripts without having to modify crontab. While this probably would have worked, we rejected it as making us diverge
too far from standard news setups. The fixes and scripts
made available by the general community of news managers are
invaluable in running news. Wholesale modification would
have made tracking those fixes tedious and error-prone.
Our next attempt focused on using cron. We modified
all the crontab entries so that they did a su to news before
actually invoking the maintenance script. Note that Berkeley cron has a feature to do this automaticly, but we were
not running BSD everywhere and desired to keep crontabs as
similar as possible. While this worked, it resulted in a
rather baroque crontab (assuming that's not redundant) and
still left the problem that any modification to crontab
itself must be done by root.
At this point we got lucky in the person of Paul Vixie.
Paul was looking for someone to beta test a new PD implementation of cron, cron2 [4].
Cron2 works rather like System V
cron [5]
but has additional small but powerful features
which have eased it's use.
Like System V cron it is significantly better
about error handling, security and reporting
than other crons. Most important, it allows users to have
individual crontabs which are always executed as the user,
not root. Vixie cron worked fine even in beta release (it
has been submitted to comp.sources.unix as of this writing)
and quickly went into general release on our systems,
displacing the vendor-supplied crons.
Two particular features of Vixie cron must be mentioned.
First, it allows definition of a user to be contacted
whenever a script has unexpected (untrapped) output.
Thus the usenet alias can continue to receive all incoming
messages (presumably both the prime system admin and the
news admin would be interested in these), while ordinary
cron messages would go strictly to the news admin.
Second, it allows an alternative PATH to be specified
for all invocations from a crontab. This permits one to
place all administrative scripts in a separate directory not
in the standard user path but does not require `hard paths'
in the shell scripts. This reduces system clutter and makes
the scripts more readable and maintainable. It also
increases system security in several ways.
First, an explicit path defeats several known security holes; second, one
can make the script directory inaccessible to ordinary
users.
This done, we proceeded to use the system. To our
pleasant surprise it worked almost immediately, with most of
the tuning done on the shell scripts.
When Bnews patches 15-17 came out, we were able to
install them over the existing software without requiring
root. Similar results were obtained with rn [6]
and nn [7].
When we converted to NNTP-based news, root was required only
to create new programs in areas such as /bin.
When the time came to convert to Cnews, we were able to
administer it as news immediately. No script or program
modifications were required. The installation method for
Cnews is rather baroque, and will require root intervention
for the foreseeable future.
Our news administration has been done on BSD 4.3 and
System V.2 without root for approximately a year; on Ultrix
for 5 months. It is now being ported to SunOS 4.1.
With news in place, the next task was uucp. This too
proved easier than expected. Building on our lessons from
Vixie cron, it took only odd moments across a week
to convert to non-root administration.
One might ask why bother with uucp? We have between 45
and 60 uucp connections at any given time, and are regularly
adding or deleting them. Often queues or locks need to be
reset, and we run an extensive set of trouble-watching
scripts.
Uucp administration also maintains and updates our
pathalias [8]
database and maps. This required some careful
division of responsibility between news and uucp, but has
been running as a stable system for some time.
Creation and deletion of uucp login accounts still
requires root intervention, but all other work is now done
by the uucp account. This system has been in production use
on BSD 4.3 and System V.2 for approximately a year. As of
this writing we are converting it to HDB uucp on SunOS 4.1
and Ultrix 4.0.
We are convinced by our initial success than many subsystems could be broken away from root. Other more pressing
tasks have prevented us from addressing them, but we hope to
return to them by the end of this year. Some of these are
listed below, with preliminary thoughts on difficulty.
Like news and uucp, it should be possible to administer
the line printer spooling system without requiring root.
Informal contacts suggest that plp, the public domain
replacement for BSD-style spooling, could easily be used for
this purpose.
There are additional difficulties which come from the
overuse of the daemon account, see below for more on this.
We are convinced it is possible to administer mail
without requiring root. What we are not yet convinced of is
whether it is worth the effort. Such things as alias files,
sendmail or smail configurations, etc, could be managed from
an unprivileged account with relatively little effort.
Going beyond that may require massive effort, and the early
returns say it would probably not be worth it for a single
site.
Mail too suffers from the overuse of daemon.
To be a candidate for non-root administration, a subsystem must be relatively self-contained and require few or
no suid root programs.
Once those are met, a relatively
small number of rules will help get the job done.
Dividing work between the news and uucp accounts proved
interesting.
Consider the case of comp.mail.maps and pathalias.
Once uucp maps have been unpacked for pathalias and
queued to remote systems there's no point in keeping them in
the news system.
But who should be responsible for what?
Currently the news system has responsibility for unpacking
the maps and creating the pathalias database.
This is
because any other solution would have required giving uucp
permission to delete or modify files owned by news.
But the
pathalias database in properly the province of uucp, not
news.
Since we only maintain one map set for our entire
network, we build several databases on one central system
and distribute them as needed.
Our initial selection was functional, but probably is
not optimal.
Doing this as news requires a news account on
all systems, regardless of their having news.
A better
breakdown would be to have news unpack and install the maps,
then perform expires on comp.mail.maps after enough time has
passed to feed our neighbors.
Uucp should be creating and
updating the databases.
As one possible solution to above, we considered having
a single account to manage both systems.
We rejected this
on two grounds.
First, it violated the rule of keeping
separate systems separate.
Second, it could lead to errors
when suddenly the entire news system seems to be owned by
uucp or vice-versa.
Location of homes for uucp and news accounts turned out
to be important.
Putting them in /usr/lib/news or
/usr/lib/uucp quickly turned out to be a bad idea.
Any
account has a lot of files associated with it, and having
those files appear in the system management areas quickly
leads to confusion.
The best solution was a subdirectory
under each of these that was the home for the account.
We were concerned that having uucp someplace other than
/usr/spool/uucp or /usr/spool/uucppublic might lead to problems
with files being delivered to unexpected places; in
practice this has not been a problem.
You can run without root using even the oldest, creakiest cron.
It's just a lot easier with a good one.
Standard
system V cron is the minimum acceptable for our systems,
Vixie cron the preferred solution.
Once you've converted to non-root usage, never get lazy
and do something as root.
More than once this has broken
things in strange and subtle ways.
The most common problem
comes from running some news or uucp script as root.
The script leaves behind files owned by root rather than the
administrative id.
These files are usually no longer usable by the subsystem,
causing lots of interesting problems.
In general, once you've converted a subsystem to non-root
administration, don't go back.
One of the difficulties we see in converting some systems
to rootless administration is the gross overuse of the
daemon account.
Some mail logs use it, the line printer
spooler uses it, everybody and their worms’ mother uses it.
This might have made sense once, but no longer does.
Giving a daemon user account would award the owner
power over a large number of different subsystems.
This is
not acceptable for reasons of security, safety, and
compartmentalization.
Any subsystems we administer from non-root
accounts will not use daemon.
It is not difficult to design subsystems such that
rootless administration is possible.
Such systems as backups, batch processing,
network management, etc, could very
easily be administered without root.
Given such tools as
suid root perl scripts, even tasks like user account
management could be done without requiring root.
If this is true, why doesn't it happen more often? The
primary reasons seem to be:
All of these are solvable problems; we hope this paper
has at least partially lit an unnecessarily dark corner.
[1] M. Glickman, M. Horton, R. Adams,
"USENET Version B Installation"
from "UNIX System Managers Manual, 4.3 Berkeley Software Distribution",
Computer Systems Research Group,
Computer Science Division,
Department of Electrical Engineering and Computer Science,
University of California, Berkeley, April, 1986. SMM:10.
[2] G. Collyer,
"Installing "C News" Network News Software,"
CNews documentation.
Posted to comp.sources.unix volume 19, 1989.
[3] Cron(8) manual page, from
"UNIX System Managers Manual, 4.3 Berkeley Software Distribution",
Computer Systems Research Group,
Computer Science Division,
Department of Electrical Engineering and Computer Science,
University of California, Berkeley, April, 1986.
[4] P. Vixie, unpublished cron2 documentation.
With cron2 beta release software, December 1988.
[5] Cron(8) manual page, "SunOS Reference Manual, Volume
III", Sun Microsystems, Revision A, March 27, 1990.
[6] L. Wall, rn installation documentation and scripts.
Posted to comp.sources.unix, volume 1, 1985.
[7] K. F. Storm, NN usage and installation documentation.
Posted to comp.sources.unix volume 22, 1990.
[8] P. Honeyman and S.M. Bellovin,
"PATHALIAS or The Care and Feeding of Relative Addresses,"
"USENIX Conference Proceedings", Atlanta, Summer 1986.
Practical Experience
The News Subsystem
UUCP
Other Possibilities
Line Printers
Mail
Prescriptions For Rootless Subsystems
Distribute Responsibilies Carefully
One Account, One Purpose
There's No Place Like $HOME
Get A Real Cron
Never Use Root!
Daemon Considered Evil
Future Directions
References
Back to Steve's home page.
Contact, License and Copy Issues.