[920] in linux-security and linux-alert archive
Fwd: [linux-security] security idea
daemon@ATHENA.MIT.EDU (Cosimo Leipold)
Wed Jul 17 12:13:31 1996
Date: Tue, 16 Jul 1996 01:37:14 -0400 (EDT)
From: Cosimo Leipold <leipold+@andrew.cmu.edu>
To: linux-security@tarsier.cv.nrao.edu
>Suid root programs might still have to start as root, to listen on a
>priviliged port for example, but could then relinquish this uid 0 for uid
>super, and do what they need to do. Sendmail is a good example.
If what you are suggesting is a simple "be root when you need to
be", a lot of programs out there already do this. They may have
something along the lines of: setuid(0); do what you need to do;
setuid(X). This works fine, but the fact remains, that for a certain
period of time there is still a uid 0 situation.
>Programs running as super could mess up users files, but not the
>"system" files owned by root, which strikes me as a definite advantage.
True.... to some extent..but the bottom line remains that if the
program is setuid 0 at any point and time, chances are some exploit will
be created that works even if the period of time is only a fraction of a
second. Even if it was not root at any time, a shell of setuid anything
is one shell to many for me. Ideally something like /proc filesystems
would be nice.
A thought of my own...many systems have users which are known to be
somewhat malicious or questionable. Therefore, one may wish to deny
access to setuid programs to these users. Of course, this is completely
pointless in respect to new users who you have little information about,
but it often happens that someone is caught attempting something,
nothing really dangerous but none the less something that could be
interpreted as a hack attempt. You could change some setuid programs to
exclude access for this one person. This could be done by making them
group executable and then simply having only that group execute it, but
including everyone but one user seems to be a pain. If on the other hand
you incorporated something like:
if (getuid() == (uid_t)UID_VALUE) { puts("Sorry. Access Denied."; exit(0); }
This, like mentioned before, is useless for external attacks but for
users on a system which seem to be potentially malicious, it might help.
You could not do this on programs that every user needs (i.e. dont do it
on passwd), but on some setuid programs that need uid 0, that general
users could be granted access to, this is a nice way of eliminating some
potential malintended users.
Cosimo Leipold
Carnegie Mellon University Pre-College Summer Programme
email: leipold+@andrew.cmu.edu
(Yea, I'm only a "kid")
