Re: "valid shell"s

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

On 7-Feb-08, at 3:49 PM, der Mouse wrote:
> Actually, from a dogmatic point of view, the correct thing to do is to
> wall them off from the "valid shell" concept, to make them stop  
> abusing
> it by equating it with other things.

Indeed.

If I'm not mistaken the "valid shell" concept originated with chpass 
(1)/chsh(1), which, to be secure for systems which have a combination  
of interactive general-purpose computing users as well as special non- 
general-purpose users which must not change their login shell,  
definitely does require that there be some way of defining a limited  
set of pathnames for programs which chpass/chsh will allow a user to  
choose as a valid interactive shell to be set as their default login  
shell.

I.e. a "valid shell" is really "a program which is valid for  
selection by the user as their default login shell when they run  
chpass/chsh".  And it is only that.  The implication is that a valid  
shell also conforms to the basic command-line API features assumed  
for login shells is true, but that's as far as it goes.  /etc/shells  
is _only_ a list of shells that users who already have one of the  
listed shells as their login shell can then choose from should they  
wish to change their login shell.  The listed shells are "valid" for  
choice as login shells by users who already have one of the listed  
shells as their login shell.

I was somewhat stupified by the fact the API implementing the lookup  
functionality (i.e. getusershell(3)) was put into libc of all places  
(instead of perhaps libutil).  It has no general purpose beyond use  
by a very few special systems programs.

The original use of this getusershell(3) (usually by calling it from  
private implementations of variants of your proposed API) in places  
like chpass(1) and even pwd_mkdb(8) was, well, quite valid and as a  
shared implementation with a defined API it made sure there was only  
one common hunk of code that would need to be changed if anything  
about /etc/shells was ever to be changed.

However the original use of this API in ftpd(8) was more  
questionable, but keep in mind that the idea was not to grant access  
to certain users, but rather to deny access to those same few special  
users who were given custom login shells which they were not  
permitted to change.  Similarly the original /etc/ftpusers did not  
grant access, but rather only denied access.  I think the distinction  
is important and the resulting implication is quite appropriate for  
the type of general purpose multi-user computing environment being  
supported by 4.3BSD at the time.

(The use of getusershell(3) in su(1) is also a bit questionable -- it  
doesn't really make any sense to restrict anyone who knows the  
password of a "special" user from general purpose system access as  
that special user, unless perhaps there is no password at all for  
that special user.  Even so access via "su" is still only granted to  
already authenticated and authorized users and audit records are  
created to record such access.  That is unless of course the security  
model for protecting configuration files and similar things normally  
used by anonymous logins to that special user was not sufficiently  
well designed and implemented, but even that's no real excuse.)

I think it was still a big assumption to make to use /etc/shells as a  
control for ftpd (i.e. that users who don't have "valid" interactive  
shells should also be denied the privilege of being able to "login"  
using ftpd).  However Unix admins being the lazy sort we are, having  
a short-cut to implicitly denying ftpd access to all "special" non- 
interactive users was, and usually still is, generally a safe  
default.  (I haven't checked the code, but I'm hoping /etc/ftpusers  
trumps /etc/shells these days now that the former has much more  
complex semantics than it originally had.)

Given the extensions to NetBSD's ftpusers(5), I'd be just as happy to  
remove the use of shells(5) in ftpd(8) and anywhere else it's being  
used to stretch the meaning of "valid" shell in the chpass(1) sense,  
including su(1).  Too bad it can't so easily be removed entirely from  
libc.

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