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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
