From owner-freebsd-security Mon Jul 7 10:08:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24208 for security-outgoing; Mon, 7 Jul 1997 10:08:42 -0700 (PDT) Received: from cmu1.acs.cmu.edu (CMU1.ACS.CMU.EDU [128.2.35.186]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA24201; Mon, 7 Jul 1997 10:08:36 -0700 (PDT) Received: from apriori.cc.cmu.edu (APRIORI.CC.CMU.EDU [128.2.72.117]) by cmu1.acs.cmu.edu (8.8.2/8.8.2) with SMTP id NAA14803; Mon, 7 Jul 1997 13:08:34 -0400 Date: Mon, 7 Jul 1997 13:08:32 -0400 (EDT) From: Robert N Watson X-Sender: rnw@apriori.cc.cmu.edu To: "Jonathan M. Bresler" cc: freebsd-security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <199707062150.OAA07546@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 6 Jul 1997, Jonathan M. Bresler wrote: > Jordan K. Hubbard wrote: > > > > > I also spent a couple of hours fighting with Alta Vista looking for relevant > > > documents and didn't find very much. Any other suggestions? > > > > /usr/src? :) > > > > Seriously, I doubt you'll find that anyone has sat down and documented > > this aspect of the system specifically. If you want to study the > > security implementation in detail, the sources remain the first and > > foremost resource. In fact, they probably represent the ONLY resource. > > Good luck! > > in a nutshell, the security model is > "you must have permission to do something". > the superuser (aka root: uid 0) is can do anything. > command audit trail (logging) is not provided. > the holes have been in the implementation of that model. > the source shows the implementation. which has been of greatly > varying quality regarding security. ;( I've heard that OpenBSD now has a feature to allow non-root users to bind to <1024 ports. It would be nice to see something similar to that under FreeBSD -- half the daemons (not a verified figure) that run as root probably don't need root access, except to bind to the port (named, sendmail, web servers, etc.) I believe the OpenBSD implementation just gives this access to the daemon user (or something to that extent? Would love details), but perhaps we could go for something a little more sophisticated if it doesn't up the overhead too much on the kernel? A limited list of (port, user) (say a max of 64, except as configured in the kernel), and if the bind() call matches this for TCP, allow the program to bind, for example. An appropriate root-owned file (/etc/rc.conf?) could define those permissions in an ipfirewall-style setup, running early in the rc sequence. This would potentially open up more holes as extra configuration files have to be monitored, and add more overhead on bind() calls, not to mention adding a configuration mechanism, but not suffering from the numerous problems involving daemons running as root (without having to rewrite all the daemons) would be nice. Even the single-user unconfigurable approach (root and daemon can bind) would be better than nothing. Just a thought.. Robert Watson