The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #283 [DANGER: UUCP *can* propogate the Worm] (1 message, 1036 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/283.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: "Robert L. Krawitz" <rlk@think.com>
To: phage
Date: Sat 14:10:05 19/11/1988 EST
Subject: DANGER: UUCP *can* propogate the Worm
References: [Thread Prev: 282] [Thread Next: 287] [Message Prev: 282] [Message Next: 284]

I think that having a single "daemon" user is unnecessarily risky.
What's wrong with one "daemon" type user for each system that needs
that sort of access?  One for syslog, one for sendmail, one for at,
etc.  It's possible to go overboard with this sort of thing, but even
100 extra users (which seems the better part of an order of magnitude
more than would be needed) in the passwd file is completely irrelevant
for any medium sized site.  I don't particularly care for at to be
setuid root, given the number of people who like to hack it locally
(not at my current site, though) and botch it (for example, someone
once came up with an "at reboot" hack to allow people to run things
when the system reboots -- they were lazy and it took me all of 30
seconds to see how to break it and a minute more to type in an
example, and I'm not very good at these things).

UID's are cheap.  Overloading them in a way that compromises security
is a lose.

I'm aware that some kernels have restrictions in the number of active
UID's (licensing bogosity).  I don't have a good answer for these
cases, other than to try to get rid of these sorts of restrictiosn by
pressuring vendors.  Berkeley moved one step in the right direction in
4.3; the trend toward using more UID's and GID's for security purposes
has a long way to go.

harvard >>>>>>  |		Robert Krawitz <rlk@think.com>
bloom-beacon >  |think!rlk
topaz >>>>>>>>  .		rlk@a.HASA.disorg

END OF DOCUMENT