From owner-freebsd-security Wed Jul 30 07:18:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA03509 for security-outgoing; Wed, 30 Jul 1997 07:18:27 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA03503 for ; Wed, 30 Jul 1997 07:18:25 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id KAA08313 for ; Wed, 30 Jul 1997 10:18:16 -0400 (EDT) Date: Wed, 30 Jul 1997 10:18:16 -0400 (EDT) From: Robert Watson Reply-To: Robert Watson To: security@freebsd.org Subject: Secure FreeBSD distribution issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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/