On 10/3/2016 3:02 PM, Stephen John Smoogen wrote:
On 3 October 2016 at 16:53, Toby Goodwin <toby@xxxxxxxxxxx> 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@xxxxxxxxxx. 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
