On 29 September 2016 at 20:55, Kevin Kofler <kevin.kofler@xxxxxxxxx> 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-ESXI5-000046 >> ] 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 J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
