[761] in linux-security and linux-alert archive
Re: [linux-security] standard users,groups,perms?
daemon@ATHENA.MIT.EDU (shaggenbunsenburner)
Mon Jun 10 14:12:16 1996
Date: Thu, 6 Jun 1996 17:47:28 -0400 (EDT)
From: shaggenbunsenburner <shagboy@thecia.net>
To: Maarten Ballintijn <maartenb@nicetech.com>
cc: "Joseph S. D. Yao" <jsdy@cais.cais.com>,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199606061202.OAA10755@pcnice1.nicetech.com>
On Thu, 6 Jun 1996, Maarten Ballintijn wrote:
> > I always insist that absolutely nothing at all whatsoever on the file
> > system be owned by root. Nothing. At all. Unless there is no other
> > way to do it (whatever the "it" might be). There should be a small set
> > of accounts whose passwords are protected equally as well as root's,
> > that are used for maintaining the various parts of the system. These
> > would be, e.g., bin, sys, adm, daemon, kmem, mail, uucp, lp, games,
This goes against almost every security policy I've ever seen, which all
make a big deal of "single point of failure". Single point of failure
means that, possibly, one thing could bring down the whole system, but
it's a hell of lot easier to guard against one big thing than a bunch of
little ones. It's like the quote in "Firewalls & Internet Security" -
The fool says "Don't put all your eggs in one basket," but the wise man
says "Put all your eggs in one basket and WATCH THAT BASKET!"
In any case, I've talked to a lot of people who feel that a total system
crash is actually EASIER to recover from than a partial security breach.
If someone gets root and does an "rm -rf /", well, you're down for a
couple of hours while you restore from the backup tape (you DID make a
backup, didn't you?) and that's that. OTOH, if a couple of system
binaries are replaced with trojan horses, you've got to go through the
entire system and make sure nothing else has been compromised and that
there are no new back doors.
> > field, etc. Directories and files - ESPECIALLY setuid programs (and
> > more of those should be setgid) - should be owned by one of these, and
> > NOT by root. This would reduce immensely the number of times that it
> > would be "necessary" to be root to perform some task or other; and thus
> > the number of windows of opportunity for certain types of attack - and
> > for simple mistakes.
Not necessarily - because of UNIX's security model, you still need
superuser privilege to do certain things on the system. It doesn't
matter whether you call yourself "root" or not, you still need it.
Granted, there are a LOT of things that are done as root that really
don't need to be (almost every MTA quickly comes to mind). But, in the
example of mail I just mentioned, if someone gets SGID mail access
through a bug and hoses the mail spool, it's not any better than if he
got root and did that. Well, okay, maybe a LITTLE better, but the
configuration headaches involved would make it about the same.
> A small example, if /, /bin, /etc, /lib are not owned by root, then the
> uid owning these dirs (and there are many more) is equivalent with
> the root account. The cops package was based on this chaining principle
> already many years ago.
Exactly. It doesn't matter "who" owns things, they're still vulnerable
to attack.
> > 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?
shag
Judd Bourgeois | When we are planning for posterity,
shagboy@thecia.net | we ought to remember that virtue is
Finger for PGP key | not hereditary. Thomas Paine
