[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: "valid shell"s
On 8-Feb-08, at 1:50 PM, Steven M. Bellovin wrote:
The issue was uucp, plus a few other utility logins with no
a well-known password: games, sync, etc. It's not so much a
non-interactive shell that's barred as special-purpose shells.
(by "non-interactive" I sort of did mean those same special-purpose
shells, eg. those which are not general-purpose un-restricted command-
line interpreters for interactive use)
I still don't really see the issue with why ftpd(8) really needed to
use getusershell(3), and even less so for su(1).
Ftpd(8) as it appears in the 4.3BSD release when getusershell(3) also
first appeared already had sufficient access control in the form of /
etc/ftpusers which could very well have been used to bar filesystem
access to all non-interactive (i.e. non-general-purpose shell) users,
including all those kinds of special-purpose accounts you mentioned.
Perhaps there was some more fine-grained hackery in between 4.2BSD
and 4.3BSD which allowed the flawed concept of using /etc/shells to
spread beyond control before /etc/ftpusers was available?
I agree that as a quick-and-dirty short-cut hack, it was generally
OK, but it did lead to some confusion as we see today.
However I think even considering /etc/shells to be some form of
access control is an incorrect interpretation right from the get-go.
It's just a courtesy check (albiet an enforced one) which prevents
ordinary users from assigning themselves a login shell which might
not work as they expect. It's a way for sysadmins to tell users they
know better than anyone else, and a way to avoid having to waste time
saving users from their own mistakes. I.e. special-purpose
restricted users should never be allowed to invoke chpass(1) or chsh
(1) in the first place. Depending on chpass/chsh to enforce part of
the restricted user security model is, I firmly believe, a direct
flaw in that security model in the first place.
I've often thought
that there was a simpler solution than /etc/shells -- have the ftpd
login program invoke $SHELL/real-ftpd when you logged in. If you
pseudo-shell, that wouldn't work, so no harm would be done. It would
also separate the login section of ftpd from the commands, itself a
very good idea that I've written about elsewhere.
Do you mean something more like "$SHELL -c 'path-to-real-ftpd'"?
Indeed that would seem to be a good idea too, and far more fail-safe
than even the hack of using /etc/shells. (though I can see it now
that some short-sighted programmer would then proceed to add a "-c
command" parameter to something like uucico! :-))
Greg A. Woods; Planix, Inc.
Main Index |
Thread Index |