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