tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "valid shell"s

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.


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.

Home | Main Index | Thread Index | Old Index