tech-userlevel archive

[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 password or
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 had a
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.

Home | Main Index | Thread Index | Old Index