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