Date: Wed, 30 Jul 1997 10:18:16 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: security@freebsd.org Subject: Secure FreeBSD distribution issues Message-ID: <Pine.BSF.3.95q.970730100736.8165C-100000@cyrus.watson.org>
next in thread | raw e-mail | index | archive | help
Some discussion recently (much thanks to Vinnie :) has centered on removing common security problems and unnecessary features from FreeBSD on a particular variation of installation. This would make some features optional, removing a number of unnecessary SUID programs. Additionally, turning off rcommands has been suggested, setting a default secure-level and determining which files should have immutable/append/etc flags set on them, as well as a set of guidelines for removing any other features that admins would be interested in. Additionally, some other issues come to mind: 1. A list of setuid programs, and why each is justified; also which can be removed in various situations. 2. A kernel flag added that disables the operation of any setuid functionality (by default not listed in the kernel config file, and by default allowing setuid.) This would break much local mail delivery, password changing in non-distributed environments, uucp, and a number of other nifty things, but would be good in a distributed environment involving NFS mounts, Kerberos or NIS, and use of secure-levels. It would reimpose the rigorous "privleges can only ever be lossed, never gained". 3. Work with the gid/uid issues on binding ports < 1024, allowing programs such as web servers to bind as non-root, lowering the number of situations where root access is required for a daemon. By default, at least intially, this would be off, or uid required to be 0 for all of these ports. A secure distribution might have this turned on, and a modified daemon-set? Other ideas that might be useful in such an environment? The goal, I think, is not to provide a completely iron-clad environment, just one where fewer priveleges are required to perform operations that have previously required more privelege than desirable, and a reduced set of setuid utilities that might be unecessary. As a possible first step, the disabling of clearly developmental setuid programs, such as suidperl, with instructions on reenabling it in the previously mentioned document (probably just chmod u+s /usr/bin/sperl), etc. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Security Research, Trusted Information Systems http://www.tis.com/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@tis.com http://www.watson.org/~robert/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970730100736.8165C-100000>