>>>>> "Greg" == Greg A Woods <woods@most.weird.com> writes:
    Greg> I don't agree there.  I've found in real life installations that a well
    Greg> written security policy will always dictate where passwords are allowed
    Greg> in the clear from (for example), not who's allowed to use them.

  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.

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

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

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

  Never heard of this. Is it in pkgsrc?

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

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [