Date: Tue, 9 Jun 1998 16:24:21 -0400 (EDT) From: "Matthew N. Dodd" <winter@jurai.net> To: The Hermit Hacker <scrappy@hub.org> Cc: Wm Brian McCane <root@bmccane.maxbaud.net>, isp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Radius login via getty Message-ID: <Pine.BSF.3.96.980609143102.17992E-100000@sasami.jurai.net> In-Reply-To: <Pine.BSF.3.96.980609114045.13066M-100000@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jun 1998, The Hermit Hacker wrote: > There is a pam_radius module out there, if you get the PAM stuff > installed on your system. I'm running it successfully under Solaris 2.6 Touching on this subject was a previous discussion of policy based login handeling. (when/where/method based restrictions) Was there ever a design proposal submited? We have a number of different combinations to resolve and a solution that is configurable not unlike IPFW (rule chains) might be a win. Time based restrictions: window access - logins are allowed during specified 'windows' ie: 9am to 5pm metered access - sessions debit against a 'units of time' over 'units of time' quota ie: 40 hours a week, or 2 hours a day or 10 hours a week and no more than 3 hours a day. This sort of limitation will probably be low on the list of things to address as it is fairly complex and requires keeping track of state (and requires tools to manage that state). Local/remote login restrictions: Local - devices local to this system. Where local may or may not be an arbitrary qualifier ie: directly attached (console, serial ttys.), this imediate network, these specific IP addresses etc. Remote - devices remote to this system. Again arbitrary but may be implicately those devices that are not covered by the 'local' case. Secure/insecure restrictions: secure - method is 'secure'. May be arbitrary or not. Probably denotes that traffic may be difficult to impossible to intercept. insecure - method is 'insecure' . Again arbitrary but may be implicately cases not covered by the 'secure' case. We've got a number of different authentication systems to choose from as well (and must take into account their needs.) - flatfile username/password (normal, default fallback etc) - YP/NIS - NIS+ - S/Key - .rhosts - RSA (via ssh) - Kerberos 4 - Kerberos 5 - Radius - LDAP? - External database/flatfile etc? - ACE/SecureID and others I'm probably forgetting. We've got a number of authentication consumers as well: login SSH ftp pop3 imap httpd XDM xlock etc... again others that I'm probably forgetting. If anyone with VMS or Novell Netware experience would like to add their opinions about tho options provided by those systems for this sort of thing I'm sure it would benefit this discussion. I think the only thing we really agree on is the ability to authenticat against /etc/passwd (well, however you hash it) is a must. This allows access under single user mode and as a fallback for local logins. Using shared libraries for implementing this should not be a problem so long as we are able to dlopen() them from static binaries. (Or we simply not reference /bin and /sbin once the system is multiuser and rely on dynamic versions of the programs in /bin and /sbin to be installed in /usr/sbin and /usr/bin). Comments? How do we configure it? How do we manage it? How do we audit it? What interfaces must be defined? Will those interfaces allow for arbitrary challenge/response? ... /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980609143102.17992E-100000>