Date: Wed, 10 Mar 1999 22:10:46 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Janos Mohacsi <mohacsi@iit.bme.hu> Cc: freebsd-security@freebsd.org Subject: Re: disapointing security architecture Message-ID: <Pine.BSF.3.96.990310210010.27517H-100000@fledge.watson.org> In-Reply-To: <Pine.GSO.4.05.9903102243200.17395-100000@bagira.iit.bme.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Mar 1999, Janos Mohacsi wrote: > 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 Unfortunately, I can't help in this area--from previous inquiries, it is my impression that improvements in PAM/etc are on the way. > 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 ;-) It is my impression that auth.conf is no longer needed, although if as you point out some of the other daemons are still using the old auth code, it is probably still used by them. > 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. I believe an idled is available via ports, if you haven't seen it yet. > 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) At one point in the past, I assembled a setuid manager that allowed policy to be set on these things. I never took it much further due to time constraints and other priorities (see below). > /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. I would comment that the security architecture for FreeBSD is being actively developed: in the past 6 months, a new version of kerberos, PAM support introduced, and more. While I can't answer your questions about particular in-progress changes, I can suggest that the chances are high they will be addressed soon :-). As additional sign that interesting things are happening out there, I volunteer that I am working on a POSIX.1e implementation for FreeBSD, and that the auditing component is almost completed, and a first pass will be released sometime in the next few days (current delays due to other time commitments). Similarly, documentation projects such as security(8) and Yan's how-to have been improving awareness; limitations on inetd and friends have helped to reduce vulnerability to denial-of-service issues. However, more people contributing to the pool can always help :-). If you have the time or energy to turn some of your suggestions into implementation (that is, perhaps a set of patches to the Makefiles to improve permissions, etc) that would no doubt greatly be appreciated by all parties involved. The send-pr mechanism is usually the best way to submit such changes+rationale, along with a CC: to -security documenting them to encourage someone with commit rights to deal with it, or at least raise some discussion about the changes. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" 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.990310210010.27517H-100000>