Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Small, Jim (jim.small_at_eds.com)
Date: Sat Dec 21 2002 - 10:15:22 CST
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
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.
On Thu, Dec 19, 2002 at 02:34:15PM -0800, Brian Hatch wrote:
> To have no shell, you'd want
> or something similar. Many folks use '/bin/false' for
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