[1543] in linux-security and linux-alert archive
[linux-security] Re: Re: [Linux UID/GID 'Feature']
daemon@ATHENA.MIT.EDU (John Goerzen)
Tue May 13 04:33:35 1997
To: linux-security@redhat.com
Cc: augustus@stic.net
From: John Goerzen <jgoerzen@complete.org>
Date: 12 May 1997 22:20:52 -0500
In-Reply-To: R.E.Wolff@BitWizard.nl's message of Mon, 12 May 1997 15:47:00 +0200 (MET DST)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
R.E.Wolff@BitWizard.nl (Rogier Wolff) writes:
> Say you've been closing accounts by adding #'s on SunOS for years and
> now are administrating a Linux machine. Surprise, that annoying cracker
> you thought you threw off, now suddenly has root priviliges. Bad thing.
This behavior is not part of any spec that I've ever seen. I hardly
understand why anybody would put # signs in the uid field. It is
certainly undocumented, and anything undocumented, especially in one
of the most important security files on the system, should send a
shiver down any good sysadmin's spine.
Common sense ways to achieve this effect wihout breaking the format of
/etc/passwd:
* Invalidate the password -- add a * in front of the crypted password
or replace it with a *. Will effectively block any access to the
system that uses /etc/passwd for authentication.
* Invalidate the login shell -- set it to /bin/nonexistant or
something. You could even make /bin/nonexistant be a short C
program telling them "access denied" or whatever. (This would
still allow access via FTP, however.) This could be good if you
only want to deny them shell access but still allow access via a
different mechanism.
[mod: Wietse Venema suggested another one to me last year:
* Invalidate the home directory.
-- REW]
Furthermore, if there is a person trying to hack the system, I
wouldn't be so lenient as to only star them or add # to their uid
field. I'd just whack the account in the first place, preventing them
from receiving mail, using FTP, putting stuff up on the Web, etc.
(But of course this is a matter of policy and may not be applicable in
all situations.)
> Another thing is a "#" in front of the whole line. That also doesn't work.
> You have to login as "#wolff" instead of just "wolff".
Another problem with this is that the # is a shell meta-character.
This can cause some unexpected and unwanted effects in shell scripts.
> One thing that does work is to put a "*" in front of the passwd entry.
Yes, and I don't really see what all the fuss is about since we have
several working methods that don't violate the format of /etc/passwd.
Anything that does violate the format ("#" included) should never be
used. Multiple programs parse that file, some using system calls and
some not, and anything that violates spec can cause unexpected and
undesired effects in any of those programs -- core dumps, possible
security holes, whatever.
[mod: Sometimes parts of the Linux system don't behave exactly as some
of us would have expected. If that happens in a security related way,
I like to warn everybody on this list about it. To some people this
whole issue is "against the specs", but where are the specs? Almost
everybody has learnt the specs by experimenting. As a # in the uid
field disables an account on SunOS, I thought it might be possible for
a site to be adding a # to the uid field as the standard account
invalidating method.
This is actually not much different from a warning "there is a buffer
overrun in su". It is a (to some) unexpected insecure behaviour. This
whole discussion about "I use this to invalidate an account" is not
necessary. Yes 99% of us are not affected by this issue, let us let it
rest then. Please? -- REW]
--
John Goerzen | Running Debian GNU/Linux (www.debian.org)
Custom Programming |
jgoerzen@complete.org |
