Re: Why do system users have valid shells
Russell Coker said:
> 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)
So there was a bug in the PAM code so that it ignored an invalid /etc/passwd
field. Why would the next bug not ignore some other /etc/passwd field (like
the user's chosen shell)?
>> 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.
Is the bug that "the second field of the /etc/passwd file is not enforced"
or that "when the second field of the /etc/passwd file is not enforced, the
seventh field is honored."?
>
>> How many of those circumstances rely on having UID0 access to set
>> userids?
>
> Probably all of them.
So a bug in a program which is running UID0 may cause security problems on
the system. That'll make news on slashdot at least.
>
>> (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.
It is as likely as some other bug in the privileged process.
However, I see your point. There may be circumstances where a bug would
lead to the wrong UID being assigned.
>
> 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.
I realize this particular example is probably not intended to demonstrate
the value of /bin/false as a shell, but it's hard to discuss a hypothetical
bug...
>
> A similar bug could once again be discovered in /bin/login (if you
> doubt then please audit the source ;).
If a similar bug existed in /bin/login, it sounds like it would behave
this way:A user tries username: bin with the wrong password. The user then types
their username (bob) and password (1234), and are given a UID2 shell of
/bin/sh. (thus a different UID than specified in the /etc/passwd file for
bob, _and_ a different shell than specified for bob)
Your claim is that by changing bin(UID 2)'s shell to /bin/false, this
hypothetical bug is more difficult to exploit.
And that the analogous bug where bob's shell is respected (giving him a UID2
shell of /bin/csh) is unlikely.
>
>> 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".
s%do not%should not%
The similarities:
------------------------------
ro /usr:
Blocks certain types of automated trojan horse/virus attacks
Can't stop an intruder that can run "mount -o remount,rw /usr" as root
Can be worked around for short tasks by the admin (mount rw temporarily)
system account shell of /bin/false:
Blocks certain types of bugs in authentication programs
Can't stop an intruder that can run "chsh" for a system account (either root
or the system account itself)
Can be worked around for short tasks by the admin (chsh temporarily)
>
> 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?
At the moment, nothing. Since write access to /bin pretty much 0wns the
box. But a .rhosts file (+) in /bin might not be noticed for a while. A
file in /var/empty (the home dir for sshd's privsep user) might be noticed.
I guess what I'm saying is that there are just as many ways to get access to
UID2 with "bin:x:2:2:bin:/bin:/bin/false" in the /etc/passwd. As there are
with "bin:x:2:2:bin:/bin:/bin/sh".
--Joe
Reply to: