[3092] in bugtraq
Re: /etc/shells (was Re: procmail
daemon@ATHENA.MIT.EDU (Robert Bonomi)
Thu Aug 8 16:50:35 1996
Date: Thu, 8 Aug 1996 15:04:48 -0500
Reply-To: Bugtraq List <BUGTRAQ@netspace.org>
From: Robert Bonomi <bonomi@delta.eecs.nwu.edu>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
On Thu, 8 Aug 1996, der Mouse wrote:
>
> If I might spin off a new thread from this one....
>
> >> Sendmail disallows this short things by not allowing pipes in
> >> .forward if user have not valid shell (listed in /etc/shells).
> > The problem there is that for an 'ftp only' account, the shell has to
> > be in /etc/shells, or FTP will not work (with most FTP servers).
>
> The problem here is, as I see it, that /etc/shells is all wrong.
>
> I first saw /etc/shells as a response to the "chsh to a shell
> containing colons and newlines" problem. It worked for that, kind of,
> but was way overkill, breaking the "the shell is just another program"
> philosophy by preventing people from chshing to arbitrary shells of
> their own creation.
>
> Then it got overloaded by sendmail and ftpd and probably others as a
> way of testing "is this user a real user or is it a pseudo-user that
> should be denied this service". As we're seeing here, the sets
>
> - set of users corresponding to humans
> - set of users who may use ftp
> - set of users who may use pipes in .forward files
>
> overlap but are not identical, at least for enough sites that making
> /etc/shells serve for all is not a satisfactory solution. And there
> are more sets that I could have listed above, making it even less
> satisfactory.
>
> I can see only two solutions. One would be to make each service
> maintain its own list of users that are forbidden (or, alternatively,
> allowed); the other would be to extend the passwd database (or,
> equivalently, maintain a parallel database) so as to allow tagging each
> user with arbitrary flags like "ftp access allowed" or "mail forward to
> pipe forbidden".
>
> Anyone have any comments on either, or any other alternatives to
> suggest?
And Jauar Ho replied:
+ how about extending the passwd fields one more after the shell so
+ that mine would be something like
+ auderho:x:1298:1:Jauder Ho:/export/home/jauderho:/usr/local/bin/tcsh:tf
+ with single letters representing different options , we can have 62 if we
+ use all the numerals , upper and lower cases of the alphabet. So let's say
+ that t stands for telnet allowed, ftp allowed ...
+
+ this allows pretty fine grained control over users.
Extending (logically) the password database seems reasonable.
I'd nominate /etc/shadow (/etc/passwd.adjunct, or whatever) as the
appropriate place. All of the 'concerns' are "potential abuse by
_priviledged_ programs", so, keep the stuff where -only- a priviledged
program can access it.
I would suggest that -direct- encoding of capabilities, as Jauar proposed,
is a 'not good' idea. It is _rare_ that one wants/needs to enumerate the
capabilities on a _per-user_ basis. Usually, one has certain _classes_ of
user, with common capabilites for the class. This leads to the concept
of an "usercap" (??) file, structured a la 'termcap'/'printcap', and for
which the query tools already exist. It's also general enough to allow
one to store *any* kinds of 'controls' -- booleans for 'capabilities',
numerics for quantitative limits, etc.
