Subject: Re: /etc/login.conf
To: None <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-userlevel
Date: 12/12/1999 17:35:29
[ On Tuesday, December 7, 1999 at 12:45:09 (-0500), Michael C. Richardson wrote: ]
> Subject: Re: /etc/login.conf 
>
>   I think that this is a good idea.

Me too!  :-)

>   While the listed items apply clearly to telnetd/login/rlogind, the most
> pressing need that I have is to be able to create classes of logins that can:
> 	 1) ftp, pop, login (on a dialup) but not telnet/ssh-with-plain-password
> 	 2) ssh with a password, but not ftp, pop, login, or telnet
> 	 3) login (on a dialup), but no network logins
> 
>   I don't care if we don't edit all the daemons, just so long as the
> expressive power is there.

I don't agree there.  I've found in real life installations that a well
written security policy will always dictate where passwords are allowed
in the clear from (for example), not who's allowed to use them.

I.e. most of what you request can better be implemented in /etc/ipf.conf
or /etc/hosts.{allow,deny}, or perhaps in the service daemon's on
specific configuration (e.g. ssh).

One thing though that can be of tremendous benefit though is an
authorisation server -- i.e. something like what kerberos does, but in a
far simpler fashion.  I'm currently using Eugene Crosser's WHOSON
daemon, with hooks in radiusd to tell whosond who is currently
authorised (and from what IP number), and then hooks in various servers
(smtp, pop, imap, etc.) to only allow connections from authorised users
on the IP numbers they're currently authenticated from.  Perhaps there's
some potential for integration of the WHOSON service and login.conf that
could provide a more fine grained control over authorisation too.

>   Also, force chroot for certain classes of users.

This might be interesting to try, but again I think it's something that
belongs more on the side of the daemon providing the service than on a
general "class" definition that applies to the user.

In the mean time I think it's more important to get to the first step
where NetBSD has the *same* compatible login.conf before thinking about
how new features would be added.

-- 
							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>