[ On Sunday, December 12, 1999 at 18:51:42 (-0500), Michael Richardson wrote: ]
> Subject: Re: /etc/login.conf 
>
>   Uh, assuming that you have only one class of users, and one class of
> activities, then I might agree.
> 
>   One problem that I have is that I have user's that need to be able to get
> their email via POP, and do it with a simple password, because they are
> moving from one piece-of-junk-os to another, but that they shouldn't be
> permitted to SSH in with a password, because that password will have been
> revealed, but they can SSH in with RSA.  
> 
>   At the same time, I never am in a situation where I give my password away
> in the clear, so I am allowed to SSH in with a password.

Perhaps my bull-headed campaign to outlaw passwords in the clear, even
for mailbox access, has clouded my reasoning!  ;-)

My personal opinion on the example you give above is that such a user
should not be allowed access to a secured system under any class!  ;-)
However I can see a rock and a hard place coming together very quickly
there....

I think the solution I'm using with the WHOSON daemon could indeed solve
your problem with the wandering insecure POP user if that user is
already authenticating with RADIUS or similar , but it might entail
changes to the system which would not necessarily be good for everyone
else at the same time.

Also, what about an anonymous SSH account that forced the execution of
one and only one program?  I've been able to do this with a relatively
small SSH patch (in this case to provide controlled rsync access to a
specific user on a machine where they are allowed a shell account to
copy files to a secured machine).  The problem in SSH is that it uses
the user's shell to invoke the the ~/.ssh/authorized_keys "command="
option.  While this would be OK if the user's shell was a program that
did only this, it doesn't work with the more generic use of
/sbin/nologin for such users.  The patch to fix this in SSH 1.2.27 is
available from me directly, and I'd like to get it into the official SSH
distribution, but I don't know if that'll happen.

>   I haven't gotten the config that I want yet, and I'd like it to be centralized.

What do you mean by centralized?  All on one machine?  All in one file?

I don't think the latter is possible or sane....

>   Never heard of this. Is it in pkgsrc?

WHOSON is a proposed authorisation protocol by Eugene Crosser.  More
info is available at <URL:http://www.average.org/whoson/>.

I've got a pkgsrc module for it that I can submit very soon.  I've been
integrating it into cistron-radiusd, smail, cyrus-imapd, et al, would
indeed like to see it in the pkgsrc tree.

>     >> Also, force chroot for certain classes of users.
> 
>     Greg> This might be interesting to try, but again I think it's something that
>     Greg> belongs more on the side of the daemon providing the service than on a
>     Greg> general "class" definition that applies to the user.
>  
>   Too hard to administrate.

Seems to work OK for me for those servers that already support it.  You
do *not* want this kind of stuff all in one file.

I would like to see inetd support a chroot option though, and that's
probably somewhere on my massive todo/round-tuit list....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>