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 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.
NOTES
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.
[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/show_bug.cgi?id=53963
[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
Thanks,
--
Jakub Svoboda / Red Hat Product Security
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
