From owner-freebsd-security Wed Mar 10 13:47:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from bagira.iit.bme.hu (bagira.iit.bme.hu [152.66.241.5]) by hub.freebsd.org (Postfix) with ESMTP id 74ADA150FA for ; Wed, 10 Mar 1999 13:47:21 -0800 (PST) (envelope-from mohacsi@bagira.iit.bme.hu) Received: from localhost (mohacsi@localhost) by bagira.iit.bme.hu (8.9.1/8.9.1) with ESMTP id WAA17558 for ; Wed, 10 Mar 1999 22:47:01 +0100 (MET) Date: Wed, 10 Mar 1999 22:47:01 +0100 (MET) From: Janos Mohacsi To: freebsd-security@freebsd.org Subject: disapointing security architecture Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear Fellow FreeBSD Users, I was quite interested to the security architecture of the FreeBSD 3.1. At the moment I am quite disappointed. 1. The PAM is a good thing but it seems to be integrated only into the login (with authentication). When will be /etc/pam.d for other tools too? Session Management? Account Management (how to cooperate with login.conf)? Password Management? Are there any documentation about pam_cleartext_pass_ok.so pam_radius.so pam_skey.so pam_tacplus.so pam_unix.so ? 2. What is the /etc/auth.conf? Why is it necessary? Why the /etc/login.conf model (or PAM) for authentication was good? (login.conf, pam.conf, auth.conf .... confusion.conf ;-) 3. The ideas of the /etc/login.conf was quite good. Wasn't it possible to extend it for management (session, password, authentication)? I think login.conf was quite strong in session and account management with different classification of users. The only missing thing was the sessiontime/idletime and sessionlimit management that could be done with -- idled. 4. The man page falsely advertises that /bin/rcp, /bin/rsh uses /etc/auth.conf. (May be after installing kerberos?) 5. I think some setuid root programs should be restricted to use some groups (removing setuid or execute bit for everyone): ccdconfig (necessary only for sysadmins) route (Why users wants to change routes?) fstat ( Probably not necessary for an ordinary users) cu (should be restricted for dialer group) netstat, iostat, nfstat, sysstat, vmstat, pstat, timedc, lpc (just for few admin people) /usr/libexec/uucp/uucico (publicly executable?) I think about the rule of thumb: fewer public setuids, less security hasard. 6. I think about the password update management: OpenBSD well done it. It could be configured in /etc/login.conf (based on classes). An other point OpenBSD made some steps forward: they have IPSec (PF_KEY v2 !!). 7. Opie (alternate skey): When will be integrated? Opie is part of the system but not integrated into login/telnet/ftp. Will be integrated as part of PAM? Any comment are welcome. Sincerely, Janos Mohacsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message