Jakub Svoboda píše v Po 26. 09. 2016 v 17:36 +0200:
>
> Hi,
>
>
> nologin is listed in /etc/shells since 2002 [1].
Hi,
based on the discussion, I think it is really time to remove nologin
from /etc/shells in Rawhide. Only one person objecting against the
removal is J.C. Cleaver , primarily because "bug becomes expected
feature after 14 years".
I don't think we should change this in released Fedoras ( I don't think
this is critical security hole, when you have access to local shell, it
is usually enough anyway ;) ), but adjustment in Rawhide seems
reasonable.
Any objections (other than "bug becomes expected")?
Regards,
Ondrej
>
>
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
