Christian, You always want to do security in layers. That way you avoid single points of failure/compromise. There are several reasons you would want to disable the shell as well the password for an account. Disabling the password makes it hard to login directly, but as others noted, you can still su. In addition, if you have a daemon or other program running as a user ID and someone does a buffer overflow or other exploit, it could drop you to a shell.
IMHO, The ideal solution is to have a binary program for the account shell that logs the attempt to "use" the account and then returns a non-zero value (like /bin/false). This in combination with a locked account with no password makes it virtually impossible to use an account. The logging also lets you see exploit attempts. As for your su example, there are times when you would want to do this. However, if you need to run a service like this, then make sure the account is only for this service. Make sure that the account can not access anything besides what is absolutely required to run the service. You really should put the account in a jail or chroot'ed environment. That way when an exploit becomes available, the damage will be limited. Notice that I say when not if. For any account that you don't need to su to, lock the account and put a logging/deny program in place for the shell. The fewer entry points into your system the better. Remember, defense in depth/layers is the key to security. <> Jim -----Original Message----- On Thu, Dec 19, 2002 at 02:34:15PM -0800, Brian Hatch wrote: > To have no shell, you'd want > news:x:9:13:news:/etc/news:/nosuchprogram > or something similar. Many folks use '/bin/false' for > example. I'm wondering why I would want that - until now nobody could give me a good argument although everybody learns to remove the shells :-( * If I give my users a disabled password, they cannot¹ login via passwd based ssh/ftp/pop3 etc. * But, on the other hand, I can have a su news -c /usr/local/script_running_as_user_news.sh
