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/htm... [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
Hello,
I'm linking another bugzilla [1] related to this, this one is against shells(5) man page.
nologin is listed in /etc/shells since 2002 [1].
This seems like a extraordinary mistake, and I agree with Jonathan Kamens' comment on the original ticket [1]. I note that his concerns were never adequately answered; the only response was a hand-wavy "well we did it and it doesn't seem to have broken".
As an administrator, I would expect setting a user's shell to nologin to prevent all access to the system. As an example of where this expectation fails if nologin is listed in /etc/shells: vsftpd allows access to a "nologin" user (it uses pam_shells).
I've read and re-read the original RFE [2]. The argument advanced for the change is "so that 'chsh' and other tools will allow its use without manual edit of /etc/passwd". I have no idea if that was true of chsh in RedHat 7.3, but in Fedora 24 chsh allows root to set any shell at all, with a warning if it doesn't exist, or isn't in /etc/shells.
With nologin absent from /etc/shells, non-root users are prevented from using chsh to change their own shell to nologin, but this seems like a feature not a bug. I can imagine in my student days "chsh -s /sbin/nologin; clear" would have seemed like the ideal prank to type into an unattended terminal!
Can anyone name the "other tools" that R P Herrold might have had in mind? I've found system-config-users which only allows setting a shell listed in /etc/shells. One remedy would be for system-config-users to follow the lead of chsh, and allow any shell to be set with a warning.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c6 [2] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c0
Toby.
On 29 September 2016 at 04:54, Toby Goodwin toby@paccrat.org wrote:
nologin is listed in /etc/shells since 2002 [1].
This seems like a extraordinary mistake, and I agree with Jonathan Kamens' comment on the original ticket [1]. I note that his concerns were never adequately answered; the only response was a hand-wavy "well we did it and it doesn't seem to have broken".
One of the reasons for it to be in /etc/shells was that various audit systems failed an OS if it wasn't. [Various government and bank security audit tools have rules like https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-... ] The second reason was that outside scripts would fail because chsh was giving an 'error' that nologin was not there.
While it can be argued that these are problems with other parties what was happening is that they haven't been fixed in multiple years and everyone who had to have anything from a PCI to a .gov audit had to go put this in the file already. This basically then becomes a "do you need to manually add this on the system? [Y/N]" purchase checkmark for banks, credit card processors, government contractors.
Stephen John Smoogen wrote:
One of the reasons for it to be in /etc/shells was that various audit systems failed an OS if it wasn't. [Various government and bank security audit tools have rules like https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-... ] The second reason was that outside scripts would fail because chsh was giving an 'error' that nologin was not there.
So the audit tools REQUIRE you to add a critical security hole?
While it can be argued that these are problems with other parties what was happening is that they haven't been fixed in multiple years and everyone who had to have anything from a PCI to a .gov audit had to go put this in the file already. This basically then becomes a "do you need to manually add this on the system? [Y/N]" purchase checkmark for banks, credit card processors, government contractors.
Nobody should ever add this at all. And most definitely not Fedora.
The behavior the original poster pointed out: | - 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. sounds very much like a critical privilege escalation security hole to me, that should get a CVE and be fixed in all supported Fedora releases ASAP!
Kevin Kofler
On 29 September 2016 at 20:55, Kevin Kofler kevin.kofler@chello.at wrote:
Stephen John Smoogen wrote:
One of the reasons for it to be in /etc/shells was that various audit systems failed an OS if it wasn't. [Various government and bank security audit tools have rules like https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-... ] The second reason was that outside scripts would fail because chsh was giving an 'error' that nologin was not there.
So the audit tools REQUIRE you to add a critical security hole?
Yep. Been that way for multiple audit curriculum since the 1980's (Orange Book?) ? I have seen it in everything from banks, to NATO, to .gov, to scientific systems which were going to EU labs. I expect some amount of it is cargo cult but it is what it is currently. I have enough Sisyphus tasks on my plate already to add this to it.
While it can be argued that these are problems with other parties what was happening is that they haven't been fixed in multiple years and everyone who had to have anything from a PCI to a .gov audit had to go put this in the file already. This basically then becomes a "do you need to manually add this on the system? [Y/N]" purchase checkmark for banks, credit card processors, government contractors.
Nobody should ever add this at all. And most definitely not Fedora.
Well that boat sailed in 2001... so have you been removing it from your /etc/shells in the last 15 years?
The behavior the original poster pointed out: | - 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. sounds very much like a critical privilege escalation security hole to me, that should get a CVE and be fixed in all supported Fedora releases ASAP!
I am not sure you would get a CVE on it as much as a "It is working as it has been working for 30 years... fix the man page"
I don't think it is privilege escalation because the person needs to know the account with /sbin/nologins password and they need to have shell access to the system somehow. They aren't getting root, but only to something that a password was set AND they have been allowed access to a shell on the system even as a different user you have other problems already.
Stephen John Smoogen wrote:
Well that boat sailed in 2001... so have you been removing it from your /etc/shells in the last 15 years?
No, because I was not aware that Fedora had been shipping with this security hole for 15 years! Of course I immediately fixed it upon reading this thread.
Kevin Kofler
On 29 September 2016 at 21:58, Kevin Kofler kevin.kofler@chello.at wrote:
Stephen John Smoogen wrote:
Well that boat sailed in 2001... so have you been removing it from your /etc/shells in the last 15 years?
No, because I was not aware that Fedora had been shipping with this security hole for 15 years! Of course I immediately fixed it upon reading this thread.
But did you fix it?
Does removing it from /etc/shells stop the su - -s/bin/bash <accountname>? [Because it doesn't seem to] Did removing it fix any of the other concerns you had?
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Thu, Sep 29, 2016 at 9:58 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Stephen John Smoogen wrote:
Well that boat sailed in 2001... so have you been removing it from your /etc/shells in the last 15 years?
No, because I was not aware that Fedora had been shipping with this security hole for 15 years! Of course I immediately fixed it upon reading this thread.
Because you were not on the deck waving to people on shore did not mean the boat did not sail.
On 9/29/2016 5:55 PM, Kevin Kofler wrote:
Nobody should ever add this at all. And most definitely not Fedora. The behavior the original poster pointed out: | - 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. sounds very much like a critical privilege escalation security hole to me, that should get a CVE and be fixed in all supported Fedora releases ASAP!
How is this a "critical...security hole"? I seriously can't be the only person out there that intentionally sets accounts to /sbin/nologin if they don't need to log in (as another layer of security), but occasionally runs 'su -s /bin/my/shell/of/choice uid' when I need to do some work under it, can I?
In any event, this has been this way for 14 years. There are legitimate reasons for wanting a "valid" shell that, nevertheless, results in disallowing remote logins in a human-readable way. The traditional solution IIRC had been to set someone's shell to /bin/false, but I fail to see why -- 14 years later -- this is something I need to get a warning about, let alone something to be considered an actual problem. A sysadmin who runs "usermod -s /sbin/nologin" knows what they're doing.
If, as mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=53963#c7, it didn't cause a problem in the first two years, "fixing" it 12 years after that seems unnecessary. We "fix" enough perfectly-working stuff in Fedora as it is...
+1 to fixing this by updating the shells man page as indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1218302#c4
Regards, -jc
As a member of the "remove nologin from /etc/shells" faction, I have 2 technical reasons for my position. I don't think either of these points have been addressed by the "leave it in" faction.
1. Certain programs use pam_shells to check access, but without requiring that the shell is able to run commands. So far I've found vsftpd and proftpd, and I'd expect all ftp daemons to follow suit. With nologin in /etc/shells, these programs will grant access to nologin users. I find this behaviour "surprising". In general it's better for security features to default to the least permissive setting.
2. It's often been said that Unix allows you to shoot yourself in the foot, but I can't think of anything else a normal user can do that's quite as simple and drastic as "chsh -s /sbin/nologin".
I have been trying to be sympathetic to the arguments from the other side, but so far have not seen any that hold water.
1. As originally proposed [1], the change of adding nologin to /etc/shells was to allow it to be set with chsh. But in modern Fedora root is allowed to do so anyway, and I don't think it's a bug that normal users cannot permanently lock themselves out in this way.
2. Can anyone provide further detail on the "Shell variable pre-load attack" mentioned in that original ticket? It's surely far too old to be the "Shellshock" bug.
3. Stephen J Smoogen raised the issue of government / bank audit rules [2]. I was nearly swayed by this argument: it's outside my area of expertise, and in general I'd be supportive of changes to help those that have to go through such processes. But the actual page he linked to [3] quite clearly allows nologin to be omitted from /etc/shells.
How can we take this forwards? Who would have the authority to take a decision on the issue?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c0 [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [3] https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-...
Toby.
On Sep 30, 2016 05:17, "Toby Goodwin" toby@paccrat.org wrote:
As a member of the "remove nologin from /etc/shells" faction, I have 2 technical reasons for my position. I don't think either of these points have been addressed by the "leave it in" faction.
- Certain programs use pam_shells to check access, but without requiring
that the shell is able to run commands. So far I've found vsftpd and proftpd, and I'd expect all ftp daemons to follow suit. With nologin in /etc/shells, these programs will grant access to nologin users. I find
this
behaviour "surprising". In general it's better for security features to default to the least permissive setting.
I suspect a lot of admins rely on this behavior to configure users that have FTP access, but not shell access. FTP does not provide a shell session. Aside, please stop using legacy FTP, sftp via sshd does the job securely and the distinction is more or less transparent to the user.
- It's often been said...shoot yourself in the foot,
but I can't think of anything else a normal user can do that's quite as simple and drastic as "chsh -s /sbin/nologin".
I have been trying to be sympathetic to the arguments from the other side, but so far have not seen any that hold water.
- As originally proposed [1], the change of adding nologin to /etc/shells
was to allow it to be set with chsh. But in modern Fedora root is allowed to do so anyway, and I don't think it's a bug that normal users cannot permanently lock themselves out in this way.
- Can anyone provide further detail on the "Shell variable pre-load
attack" mentioned in that original ticket? It's surely far too old to be the "Shellshock" bug.
- Stephen J Smoogen raised the issue of government / bank audit rules
[2].
I was nearly swayed by this argument: it's outside my area of expertise, and in general I'd be supportive of changes to help those that have to go through such processes. But the actual page he linked to [3] quite clearly allows nologin to be omitted from /etc/shells.
Admins and auditors will expect the options for user shells to be listed in /etc/shells. /sbin/nologin is a valid option for a user's default shell. I don't see the problem here.
How can we take this forwards? Who would have the authority to take a decision on the issue?
Almost certainly FESCo. Impact to dependent software aside, compliance audits tend to be tedious and rote verification of a checklist, and the list does often address /etc/shells. IMO disruption of those expectations does warrant a Change proposal.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c0 [2]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
[3]
https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-...
Toby. _______________________________________________
-- Pete
On Fri, September 30, 2016 3:16 am, Toby Goodwin wrote:
As a member of the "remove nologin from /etc/shells" faction, I have 2 technical reasons for my position. I don't think either of these points have been addressed by the "leave it in" faction.
- Certain programs use pam_shells to check access, but without requiring
that the shell is able to run commands. So far I've found vsftpd and proftpd, and I'd expect all ftp daemons to follow suit. With nologin in /etc/shells, these programs will grant access to nologin users. I find this behaviour "surprising". In general it's better for security features to default to the least permissive setting.
The thing is, this is a well-known usage for /sbin/nologin -- one of the two canonical cases (the other being for the display of a polite message when a login is attempted). I understand that someone might find this "surprising", but... I've found a lot of things surprising over the years in Linux. I don't see why that justifies changing a 14 y/o default. Plenty of others may find its removal that much more surprising.
At a certain point, "bugs" turn into features and known, if not particularly greatly documented, behaviors. I think this is the case here.
- It's often been said that Unix allows you to shoot yourself in the
foot, but I can't think of anything else a normal user can do that's quite as simple and drastic as "chsh -s /sbin/nologin".
- As originally proposed [1], the change of adding nologin to /etc/shells
was to allow it to be set with chsh. But in modern Fedora root is allowed to do so anyway, and I don't think it's a bug that normal users cannot permanently lock themselves out in this way.
I've actually done this on a few rare occasions; I needed to do some final creation of a system account's directory structure, didn't want to bother with a recursive chown and verification of umask afterwards, and removed the default shell after me.
I've also done it a few times to prevent simple logins from certain externally-automated accounts while I'm doing maintenance, as it's quicker than exiting back to root to do it then su'ing back in if I happen to be on the box.
I can imagine cases where on larger multiuser systems a step like this could be performed by local policy. Places are weird.
I do understand that it's weird, but why are we intentionally disabling people's ability to do "weird" things arbitrarily? A sense of aesthetics?
Finally, all change has a cost; this now forces Yet Another Conditional out there in people's config/automation scripts for reasons of rather questionable importance. The fact that that's been something of the mantra of Fedora's over the past 6 years doesn't mean we need to keep on doing that.
-jc
On Fri, Sep 30, 2016 at 5:16 AM, Toby Goodwin toby@paccrat.org wrote:
As a member of the "remove nologin from /etc/shells" faction, I have 2 technical reasons for my position. I don't think either of these points have been addressed by the "leave it in" faction.
[...]
- Can anyone provide further detail on the "Shell variable pre-load
attack" mentioned in that original ticket? It's surely far too old to be the "Shellshock" bug.
Unable to find any archive of the testers-list from 2001, the BZ references. However, one could reasonably speculate based on the information given.
""" R P Herrold 2001-09-24 11:37:54 EDT
Please add a SAFE no-login type shell to the base /etc/shells -- safe in the sense that it is immune from the Shell variable pre-load attack. It needs to be here, so that 'chsh' and other tools will allow its use without manual edit of /etc/passwd
Nalin suggested /sbin/nologin on testers-list, but unlike all the other 'default' shells, this is not in /bin ...
Doesn't bother me, but ... """
Lets break it out...
"Immune from the Shell variable"
Presumably the $SHELL variable?
From the Bash manual: """ SHELL The full pathname to the shell is kept in this environment variable. If it is not set when the shell starts, bash assigns to it the full pathname of the current user's login shell. """
Okay, so the SHELL variable in bash has logic to deal with before & during shell startup. So presumably the "testers-list" email with Nalin could have been about fuzzing the $SHELL variable prior to login? Maybe back in those days one could set the SHELL variable to /usr/bin/MY-AWESOME-SCRIPT and it would actually make that the login shell?
Or perhaps by "pre-load attack" we mean something more along the lines of LD_PRELOAD and static Vs dynamic shells. Back in the old days Unix folks were pesky about their statically built login shell which were more resilient to problems, compared to linked binaries. For example statically build shell would survive the absence of libc, or whatever system library. That was handy back in old days when system libraries were placed in a (I.E. corrupted) /usr/lib/ filesystem. Anyhow... with linked binaries it's theoretically possible to pre-load adversarial things, right? I have no idea if bash these days is static or otherwise, so if you know please chime in?
Regardless, I am unable to think of any good reason to oppose Toby Goodwin's proposal around removing the nologin shell from /etc/shells. His reasoning seems solid.
-Jon Disnard
I was just reviewing this thread to date, and came across somebody asking:
How is this a "critical...security hole"?
I'm wondering if perhaps some of the staunch defenders of the status quo have missed the security hole?
One of the checks that chsh makes when running for an unprivileged user is that the current shell is a "normal" one, that is, listed in /etc/shells. chsh doesn't actually use pam_shells, but it's the same check. If your current shell is not listed in /etc/shells, you are not allowed to change it. But if your current shell is in the list, you can change it.
Suppose as an administrator, you want to lock Alice out of the system:
# usermod -s /sbin/nologin alice
She can no longer log in. But now suppose Alice has a friend Eve, who also has an account on the system:
eve$ su -s /bin/bash alice -c 'chsh -s /bin/bash' Password: Changing shell for alice. Password: Shell changed.
Now Alice can log in again. (In case it's not obvious, the first password prompt is from su, the second is from chsh, and I typed alice's password at each.)
A (non-root) user, supposedly locked out of a Fedora system with nologin, can regain access by colluding with another (non-root) user.
Does anyone still think that /sbin/nologin belongs in /etc/shells? If so, I have a ticket drafted for FESCo to make an authoritative decision. But I'd prefer to avoid taking up their time. Can we reach consensus here that nologin should be removed from shells?
Toby.
On 3 October 2016 at 16:53, Toby Goodwin toby@paccrat.org wrote:
I was just reviewing this thread to date, and came across somebody asking:
How is this a "critical...security hole"?
I'm wondering if perhaps some of the staunch defenders of the status quo have missed the security hole?
Why do people have to think that people are being 'stauch defenders' when they might just needed a clearer explanation? I know you mentioned chsh in your original email but even after rereading it, I am not able to make the leap from it to what you show below. What you show below is clearly a security problem for multi-user systems (though I expect that there would be arguments that you are not supposed to use chsh /sbin/nologin to lock someone out but usermod -L).
The owner of the setup package is Ondrej Vasik, email: ovasik@redhat.com. They seem fairly active and would probably be receptive to fixing the problem with the explanation included.
On 10/3/2016 3:02 PM, Stephen John Smoogen wrote:
On 3 October 2016 at 16:53, Toby Goodwin toby@paccrat.org wrote:
I was just reviewing this thread to date, and came across somebody asking:
How is this a "critical...security hole"?
I'm wondering if perhaps some of the staunch defenders of the status quo have missed the security hole?
Why do people have to think that people are being 'stauch defenders' when they might just needed a clearer explanation? I know you mentioned chsh in your original email but even after rereading it, I am not able to make the leap from it to what you show below. What you show below is clearly a security problem for multi-user systems (though I expect that there would be arguments that you are not supposed to use chsh /sbin/nologin to lock someone out but usermod -L).
The owner of the setup package is Ondrej Vasik, email: ovasik@redhat.com. They seem fairly active and would probably be receptive to fixing the problem with the explanation included.
My objection here is roughly the same. /sbin/nologin does not mean "locked out", it's a non-shell that can serve as a shell. While there may be some value in chsh disallowing a change *from* /sbin/nologin to something else by the own user, it's not intended to block any access at all by a user -- it's canonical purpose allowed FTP logins successfully, for example.
To prevent an 'su' specification of shell and to prevent any login, one can use /bin/false easily enough (which, again, was historical practice AFAIK). To prevent login via password (or an 'su' from one local user to another), usermod -L would seem to be more correct.
My concern here is that we're losing a useful tool: a built-in "non-shell" shell, functioning as a middle-ground between an invalid shell and an account lockout.
Regards,
-jc
My objection here is roughly the same. /sbin/nologin does not mean "locked out", it's a non-shell that can serve as a shell. While there may be some value in chsh disallowing a change *from* /sbin/nologin to something else by the own user, it's not intended to block any access at all by a user -- it's canonical purpose allowed FTP logins successfully, for example.
OK. I understand what you're saying. I suppose this boils down to what "nologin" is supposed to mean.
1. On the one hand, we have the behaviour of Fedora (and RHEL and CentOS) since 2002, with nologin in /etc/shells, which is as you describe.
2. On the other hand, we have nologin as introduced by 4.4BSD and copied by Linux, including the original RedHat distro itself before Fedora days: nologin is absent from /etc/shells, and setting it does disable all access.
I am sure that disallowing logins while still allowing FTP was *not* the original canonical purpose of nologin in 4.4BSD. Indeed, there is a currently open ticket [1] to remove this text from the shells(5) man page:
Be aware that there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file.
This text, of course, also appears in all those other Linux distros where nologin is not in /etc/shells.
To prevent an 'su' specification of shell and to prevent any login, one can use /bin/false easily enough (which, again, was historical practice AFAIK). To prevent login via password (or an 'su' from one local user to another), usermod -L would seem to be more correct.
It's true that we used to use /bin/false to disable shell access. I wasn't there at the time, but I imagine the reason nologin was invented was to make it clear to a user that their account has been disabled by printing a message, rather than just mysteriously kicking them out.
It's also true that locking the password is a good idea if you want to definitively disable an account. However, on all other systems except Fedora and friends, nologin alone does seem to be sufficient.
(Of course, ssh with key-based access does not respect locked passwords, although I've just discovered it does respect expired accounts. It would seem that "usermod -e 1 -s /sbin/nologin -L user" is the belt and braces approach to disabling an account!)
My concern here is that we're losing a useful tool: a built-in "non-shell" shell, functioning as a middle-ground between an invalid shell and an account lockout.
Well, you do of course have the option of adding nologin back into /etc/shells, or supplying your own program to do the job and listing *that* in shells. You could even try to get such a thing into the core distribution, but please don't call "nologin", as that is confusing to anyone that's used to *BSD, Debian, etc.
I contend that we have this middle ground by historical accident, not by design. If it were by design, surely all those system accounts (bin, daemon, adm, etc) would have the "definitely no access" shell, /bin/false or whatever, and not the "middle ground" shell of nologin?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1218302
Toby
Why do people have to think that people are being 'stauch defenders' when they might just needed a clearer explanation?
Stephen, I've been striving to keep my comments technically focused. That remark slipped below my own standards. I didn't mean it as a personal jibe, just a slightly light hearted way of characterizing one side of the debate. I apologize to you, and anyone else who felt slighted or offended.
I know you mentioned chsh in your original email but even after rereading it, I am not able to make the leap from it to what you show below.
Thank Jakub Svoboda, it was all there in his original ticket [1].
And thank you, Stephen J Smoogen, for having the courage to publicly change your mind!
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1378893#c0
Toby
On Tue, Oct 04, 2016 at 07:33:40PM -0000, Toby Goodwin wrote:
Stephen, I've been striving to keep my comments technically focused. That remark slipped below my own standards. I didn't mean it as a personal jibe, just a slightly light hearted way of characterizing one side of the debate. I apologize to you, and anyone else who felt slighted or offended.
Thanks, Toby. It takes extra courage to apologize, and this is a great example of how things should go on the Fedora lists.
2016-09-29 16:58 GMT+02:00 Stephen John Smoogen smooge@gmail.com:
https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-...
This is titled "All shells referenced in /etc/passwd must be listed in the /etc/shells file, except any shells specified for the purpose of preventing logins." and *doesn't* require /sbin/nologin to be in /etc/shells, or am I misreading it?
- Thomas
On 30 September 2016 at 02:25, Thomas Moschny thomas.moschny@gmail.com wrote:
2016-09-29 16:58 GMT+02:00 Stephen John Smoogen smooge@gmail.com:
https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-...
This is titled "All shells referenced in /etc/passwd must be listed in the /etc/shells file, except any shells specified for the purpose of preventing logins." and *doesn't* require /sbin/nologin to be in /etc/shells, or am I misreading it?
No you are not misreading it. I was the one misreading and misremembering it. [I do remember having to add nologin into /etc/shells on a bunch of hosts for some sort of finding but for all I know my brain is lieing to me.]
- Thomas
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On 30 September 2016 at 12:07, Stephen John Smoogen smooge@gmail.com wrote:
On 30 September 2016 at 02:25, Thomas Moschny thomas.moschny@gmail.com wrote:
2016-09-29 16:58 GMT+02:00 Stephen John Smoogen smooge@gmail.com:
https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-...
This is titled "All shells referenced in /etc/passwd must be listed in the /etc/shells file, except any shells specified for the purpose of preventing logins." and *doesn't* require /sbin/nologin to be in /etc/shells, or am I misreading it?
No you are not misreading it. I was the one misreading and misremembering it. [I do remember having to add nologin into /etc/shells on a bunch of hosts for some sort of finding but for all I know my brain is lieing to me.]
I have gone through all the old data I could find, and I was wrong on this being a finding. My apologies for the misinformation.
Kevin Kofler wrote:
I can confirm [that Debian doesn't list nologin in /etc/shells.
I've also been researching this.
1. I have checked all current versions of Debian: wheezy (old-stable), jessie (stable), and stretch (testing).
2. Ubuntu follows suit. I have checked all supported LTS versions: lucid, precise, trusty, and xenial.
3. I'm reasonably sure that /etc/shells and nologin originally came from 4.4BSD. It's thus no surprise to find that FreeBSD ships with /sbin/nologin, but does not list it in /etc/shells. I haven't checked any other *BSDs, but I'd be willing to lay a modest wager :)
4. Arch ships nologin, but does not list it in /etc/shells.
5. I looked at NixOS. It doesn't ship nologin by default. If you install the util-linux package, that gives you nologin, but it does not add it to /etc/shells. (I think. NixOS is *odd*!)
I am not arguing that popular == right. I am saying that in the absence of a compelling reason to stand out from the crowd, there is a value in consistency. Particularly where security is concerned: imagine an administrator coming a Debian background who assumes that setting the shell to nologin is a reasonable way to lock a user out of the system.
Toby.
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. notlisted 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/htm... [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-leave@lists.fedoraproject.org
On Tue, Oct 04, 2016 at 03:46:01PM +0200, Ondřej Vašík wrote:
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")?
Let's make sure to get it in the F26 release notes.
We've discussed how and whether it's best practice to disallow a user from logging into an account they previously had access to.
But now I'm sorta curious about the opposite situation: What's the use case for blocking a user from accessing their account, rather than just deleting the account altogether?
Er, let me clarify: Much of the discussion here, as I see it, has been about how to preserve a user account, but block user access to that account.
My question is: If it were really important to make sure the user could no longer access the system at all, why not just delete the account? Deleting the user does not (necessarily) delete their data, so what's the use case for keeping the account at all in such a situation?
We've discussed how and whether it's best practice to disallow a user from logging into an account they previously had access to.
But now I'm sorta curious about the opposite situation: What's the use case for blocking a user from accessing their account, rather than just deleting the account altogether?
My question is: If it were really important to make sure the user could no longer access the system at all, why not just delete the account? Deleting the user does not >(necessarily) delete their data, so what's the use case for keeping the account at all in such a situation?
In my experience, something like nologin is the best choice when you want to disable a user temporarily. For one example, suppose you run a shell server for paying customers - what should you do with a customer who forgets to pay?
If you altogether delete the account, or lock the password, they will get an authentication failure, giving them no clue as to the problem. With nologin, you have the opportunity to display a message encouraging them to make the payment. (Deleting the account outright will also destroy the password, and may cause further problems, for example their UID might be reused.)
Using account expiry might be an even better option for this scenario, but I think nologin predates that mechanism.
Toby.
Andrew Toskin wrote:
If it were really important to make sure the user could no longer access the system at all, why not just delete the account? Deleting the user does not (necessarily) delete their data, so what's the use case for keeping the account at all in such a situation?
The files they owned, which may not only be in their home directory but also in shared directories, will remain owned by the former user's numeric user ID. That user ID is now unallocated, and may get reused when a new account is created. The new user then gets access to all of the former user's files.
Björn
On Fri, Oct 7, 2016 at 8:03 AM, Björn Persson <Bjorn@rombobjörn.se> wrote:
Andrew Toskin wrote:
If it were really important to make sure the user could no longer access the system at all, why not just delete the account? Deleting the user does not (necessarily) delete their data, so what's the use case for keeping the account at all in such a situation?
The files they owned, which may not only be in their home directory but also in shared directories, will remain owned by the former user's numeric user ID. That user ID is now unallocated, and may get reused when a new account is created. The new user then gets access to all of the former user's files.
Björn
It's worse when some monkeyboy has been using "useradd" casually, without trying to prevent overlap of userid. Suddenly a *system* account, such as a hand installed apache, named, tomcat, or mysql gets a uid matching that of another system account.
Hilarity ensues.
1) /sbin/nologin does display a nice message upon login, while /bin/false does not. 2) /sbin/nologin displays the message upon login regardless of whether it is in /etc/shells or not. These two sentences ^^ describe two independent properties. Nobody loses the "message upon login" feature of nologin by nologin being removed from shells.
Let's look at the history of /sbin/nologin. According to the OpenBSD man pages nologin was introduced in 4.4BSD.
4.4BSD has both /sbin/nologin [1] and /etc/shells [2]. /sbin/nologin is not in /etc/shells. (I tried to search for the string "nologin" to see whether there is a setup script that adds /sbin/nologin to /etc/shells and found nothing [6].) So, we might think the makers of nologin either didn't want to include it or made a mistake. Since the current OpenBSD still doesn't include /sbin/nologin in /etc/shells, I'd guess it has been intentional all along.
The behavior of su in 4.4BSD is to disallow a change to a shell not listed in /etc/shells. su in 4.4BSD doesn't have the -s switch but does have the -m switch and it uses getusershell() [3]. getusershell() reads /etc/shells [4]. Internally, su has a function that changes the user shell (with -m) if it is in /etc/shells [5].
The original source code of su [5] is short and quite readable. It's clear that adding /sbin/nologin to /etc/shells in 4.4BSD would break the assumptions laid down by the man pages, the source code, and by the apparent meaning of nologin's name. The current man pages in Fedora do not suggest a change in the philosophy of /etc/shells, su, or nologin.
[1] https://github.com/sergev/4.4BSD-Lite2/tree/master/usr/src/sbin/nologin [2] https://github.com/sergev/4.4BSD-Lite2/blob/master/etc/shells [3] http://man.openbsd.org/4.4BSD-Lite2/man1/su.1 [4] http://man.openbsd.org/4.4BSD-Lite2/getusershell.3 [5] https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/usr.bin/su/su.c#L... [6] https://github.com/sergev/4.4BSD-Lite2/search?p=1&q=nologin&utf8=%E2...
-- Jakub Svoboda / Red Hat Product Security
Once upon a time, Andrew Toskin andrew@tosk.in said:
But now I'm sorta curious about the opposite situation: What's the use case for blocking a user from accessing their account, rather than just deleting the account altogether?
There are lots of reasons. For example, if someone is paying for an account, they may be temporarily blocked for non-payment. A company may block an account for an employee on extended leave. An account that is suspected of compromise or abuse may be blocked.
-
Andrew Toskin -
Björn Persson -
Chris Adams -
Jakub Svoboda -
Japheth Cleaver -
Jon -
Kevin Kofler -
Matthew Miller -
Nico Kadel-Garcia -
Nikola Forró -
Ondřej Vašík -
Pete Travis -
Stephen John Smoogen -
Thomas Moschny -
Toby Goodwin