Hi,
nologin is listed in /etc/shells since 2002 [1].This is in conflict with:
man 5 shells
DESCRIPTION
/etc/shells is a text file which contains the full pathnames of valid
login shells.
man 5 shells
DESCRIPTION
/etc/shells is a text file which contains the full pathnames of valid
login shells.
man 8 nologin
DESCRIPTION
nologin displays a message that an account is not available and exits
non-zero. It is intended as a replacement shell field to deny login
access to an account.
DESCRIPTION
nologin displays a message that an account is not available and exits
non-zero. It is intended as a replacement shell field to deny login
access to an account.
NOTES
nologin is a per-account way to disable login (usually used for system
accounts like http or ftp).
nologin is a per-account way to disable login (usually used for system
accounts like http or ftp).
man 1 su
OPTIONS
-s, --shell=shell
Run the specified shell instead of the default.
OPTIONS
-s, --shell=shell
Run the specified shell instead of the default.
[snip]
If the target user has a restricted shell (i.e. not listed in/etc/shells), the --shell option and the SHELL environment vari‐
ables are ignored unless the calling user is root.
Actual behavior and man pages are consistent for su and nologin and their behavior is affected indirectly by /etc/shells. The inconsistency lies in /etc/shells containing nologin and man 5 shells semantically telling the opposite.
Let's fix it.
The stated reason for including nologin in shells is "so that 'chsh' and other tools will allow its use without manual edit of /etc/passwd" [1]. This is argument is inaccurate. Tests on RHEL 6.0 and fc24 showed that the man page for chsh is correct - when /sbin/nologin is not in /etc/shells, root can successfully run chsh -s /sbin/nologin username. It prints a warning but it does change the default shell to /sbin/nologin. man 1 chsh:
VALID SHELLS
chsh will accept the full pathname of any executable file on the sys‐
tem. However, it will issue a warning if the shell is not listed in
the /etc/shells file. On the other hand, it can also be configured
such that it will only accept shells listed in this file, unless you
are root.
Removing /sbin/nologin from /etc/shells would prohibit a regular user to set /sbin/nologin as the default shell for themselves - an action that makes little sense.
/sbin/nologin being in /etc/shells poses security and logical problems:
- su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the default shell) succeeds with /bin/bash if auth is successful [2], even though man 1 su, man 8 nologin, and man 5 shells suggest that such a user is a restricted user and logging in with an alternate specified shell should be forbidden.
- Red Hat Enterprise Linux 7 Security Guide advises [3] that /sbin/nologin should be used to prevent direct login to an account - the root account in this example. Presumably, this should be prevented in the case where the attacker has valid login credentials for the account. In that very case, however, the attacker can use an ordinary account to run su -s /bin/bash - root because the protection for this very attack present in su is rendered useless by /sbin/nologin being listed in /etc/shells.
- selinux has a workaround for /sbin/nologin - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00893.html
- gdm has a workaround for /sbin/nologin - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00894.html
- Debian doesn't list nologin in /etc/shells. An opinion from a Debian developer [4]: "The point of having a shell that's not in /etc/shells isn't that you can't use it to log in, but that it's not a normal shell and that users with that shell set can't change it to something else. Adding nologin to /etc/shells would be very likely to open security vulnerabilities, and I will not do it."
It seems as though /sbin/nologin is listed in /etc/shells as a workaround to some issues without even documenting it in the man pages. These issues are not important enough for those distributions and OSes that don't list /sbin/nologin in /etc/shells. Maybe fedora should be on the same boat.
The rabbit hole of the past bugs and discussions about this starts here [5].
This is a bug that either lies solely in the setup package (which lists /sbin/nologin in the /etc/shells file) or it is an inter-package bug where multiple packages that are correct on their own exhibit an incorrect behavior together. In any case, it is clear *something* is wrong here.
What can we do to fix this issue or to at least to make man pages consistent with the actual behavior? Are there serious reasons to continue listing /sbin/nologin in /etc/shells?
[1] https://bugzilla.redhat.com/sh
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c0
[3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Controlling_Root_Access.html#sec-Disallowing_Root_Access
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419132#32
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c1
[3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Controlling_Root_Access.html#sec-Disallowing_Root_Access
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419132#32
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c1
Thanks,
--
Jakub Svoboda / Red Hat Product Security
Jakub Svoboda / Red Hat Product Security
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
