Re: "valid shell"s

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

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.
                                        <woods%planix.ca@localhost>