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@xxxxxxxxxxxxxxxxxxxxxxx/message/SR76Q2ZTGQDJREEMC2AE53JC4PQZISLQ/ [3] https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-000046 Toby. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
