On Sep 30, 2016 05:17, "Toby Goodwin" <t...@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. > > 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. >
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. > 2. 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. > > 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. > 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/message/SR76Q2ZTGQDJREEMC2AE53JC4PQZISLQ/ > [3] https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-000046 > > Toby. > _______________________________________________ > -- Pete
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
