Re: Why do system users have valid shells
On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
> Russell Coker said:
> > The idea of giving non-login accounts a shell of /bin/false is hardly
> > new.
>
> Out of curiosity, what security benefit does a shell of /bin/false grant,
> that say, an encrypted password of "NOLOGIN" (or equivalently "*") does not
> grant?
There was a case of a buggy pam some time ago which let people login to
accounts such as "man" and "bin". Changing the shell would have prevented
that problem (or limited the number of accounts that were vulnerable).
> In what circumstances would a process be started using the shell field of
> /etc/passwd without checking the password in either /etc/password and/or
> /etc/shadow?
Buggy program that does authentication.
> How many of those circumstances rely on having UID0 access to set userids?
Probably all of them.
> (and thus write access to /etc/passwd and/or the chsh command)
That does not follow. If a program can be tricked into logging you in as the
wrong account, that does not mean that it's actions can give any result other
than that of an authorised user logging in to that account.
As an example of this. When I initially patched the Debian login program for
SE Linux I made a mistake in handling the user-name. It was possible to type
in "root" and then the wrong password (IE you don't know the root password)
and then type in the name and password for an account you are authorised for
and login with the SE Linux privs assigned to the "root" account.
This security hole did not grant the ability to read the entire contents of
/etc/shadow (which /bin/login could potentially do if it was exploited). It
did not grant any Unix access other than the authorised access (so without
the "root" password you could not get UID 0 and your access was limited).
All it did was grant a free choice among SE Linux security contexts that were
permitted for shells spawned by /bin/login.
A similar bug could once again be discovered in /bin/login (if you doubt then
please audit the source ;).
> This is very similar to the discussion last week on "read-only" /usr
> mounts. Setting the shell to /bin/false does not change the security
> character of the system.
It's different in a few ways. Normally programs do not write anything under
/usr. So it's not a case of "fool program into writing /usr/.../a instead
of /usr/.../b".
It's more like the recent change of making /usr/bin/crontab SGID instead of
SUID.
> * A more important consideration is the location of "bin"'s $HOME.
What's wrong with the current location?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: