[249] in linux-security and linux-alert archive
Re: switching symlinks on atrun
daemon@ATHENA.MIT.EDU (Joseph S. D. Yao)
Sun May 28 08:12:32 1995
Date: Thu, 25 May 1995 15:27:18 -0400
From: "Joseph S. D. Yao" <jsdy@cais.cais.com>
To: shields@tembel.org, Thomas.Koenig@ciw.uni-karlsruhe.de
Cc: linux-security@tarsier.cv.nrao.edu
[mod: I'm approving this post as well as Thomas' reply even though
they're not very Linux-specific. Please send any follow-ups to the
authors. --okir]
From: Thomas.Koenig@ciw.uni-karlsruhe.de (Thomas Koenig)
> From: shields@tembel.org (Michael Shields)
> > From: Thomas.Koenig@ciw.uni-karlsruhe.de (Thomas Koenig)
> > > /var/spool/atrun is owned by a non - root userid, usually bin.
> > > If somebody broke into bin, he could then execute a shell script
> > > owned by root with root permissions, via a
> > But lots of things are owned by bin. /bin/sh is probably owned by bin.
> > If you have bin, you can get root, at or no at.
> Ugh... they should not be. Unless some system binary needs to be setuid
> to a particular userid, it should ALWAYS be owned by root, for exactly
> this reason.
I'm afraid that I must respectfully but strongly disagree with the last
conclusion.
I hold it as a strong security tenet that nothing on the file system
should be owned by root. Absolutely nothing at all. Unless, of
course, it will not work otherwise.
Why is this? I have two primary reasons.
The first reason is to discourage, as much as possible, the practice
some people have of doing ALL system maintenance work as the super-user.
This horrible practice makes me shudder. The super-user account has a
lot of power: it blithely ignores ALL restrictions on file system per-
missions, and gives quite a few other powers besides. If one is capable
of making mistakes - and we are all human, who has never made a mistake?
- then making a mistake AS THE SUPER-USER magnifies the possible conse-
quences of that mistake N-fold. Consequently, one of the first things
that I do on any system is to change all files and directories owned by
root - unless I can be persuaded otherwise - to some other user, typi-
cally "bin" (or "sys").
The second reason is to discourage the writing of programs that
"really, absolutely, HAVE to be" setuid-root. For at least half of the
programs that I've seen, whose authors wanted them to be setuid-root,
there was a perfectly acceptable setgid-something solution. Making a
program setuid-root, to overcome all problems with file system or other
permissions, is often just a lazy way out. Because of the aforemen-
tioned powers that a process running as the super-user has, I don't
like to proliferate such programs.
It is absolutely true that, if someone cracks the "bin" account, they
would then (under this arrangement) be in a good position to get full
control of the system. Note that they would not have full control of
the system immediately, as they would if they were to crack the "root"
account. The solution, though, is to protect ALL system accounts, be
they "root", "bin", "sys", "field" [if such exist], or whatever.
Joe Yao jsdy@cais.com - Joseph S. D. Yao
