From owner-freebsd-stable Thu Apr 16 23:44:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13479 for freebsd-stable-outgoing; Thu, 16 Apr 1998 23:44:29 -0700 (PDT) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from mailhub.NetMan.SE (mailhub.netman.se [194.52.54.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA13428; Fri, 17 Apr 1998 06:44:21 GMT (envelope-from allard@NetMan.SE) Received: (from uucp@localhost) by mailhub.NetMan.SE (8.8.5/8.8.5) id IAA23639; Fri, 17 Apr 1998 08:50:37 +0200 (CEST) Received: from localhost(127.0.0.1) by mailhub.NetMan.SE via smap (V2.0) id xma023636; Fri, 17 Apr 98 08:50:11 +0200 Date: Fri, 17 Apr 1998 08:50:11 +0200 (CEST) From: Johan Allard To: Robert Watson cc: Dima Ruban , Matthew Hunt , stable@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk Indeed something to work on. An excellent suggestion. On the whish list I would like to add support for IPsec. It must be possible to port the code from OpenBSD. Since OpenBSD is exported from Canada it is possible to use it with strong encryptions even here in Europe. If it is possible to import the OpenBSD code with regular patches using ports it would be possible to include it in FreeBSD and use it worldwide. The world indeed be a better place if we could use IPsec with FreeBSD. //johan allard > So, > > With all this discussion of various things that might or might not improve > the security of a FreeBSD system, I'd like to propose the FreeBSD > Hardening Project. What I have in mind is a port in the ports collection > that would "harden" the default FreeBSD base installation. It would apply > schg flags, remove unnecessary read/write/etc access from standard > binaries and config files, disable most daemons and inetd.conf entries, > install a more-than-minimal ipfw config, perhaps enable some kernel > settings, etc. The goal would be to move from an "open" system to one > that might be more appropriate for a router or firewall machine in a less > friendly network environment. For the paranoid, of course, it would be > appropriate for every-day use :). > > The system would then be in what many would consider an unusable state -- > the administrator could optionally reenable features as they saw fit > (i.e., incoming telnet, ftp, finger, incoming icmp, packet forwarding, > smtp, and so on). > > Does this seem like an interesting or useful proposal? When setting up a > proxy server, I really want a minimal feature set enabled, although having > the standard toolset available is always useful. The proxy user, however, > should not even be able to send packets on irregular ports, and would be > restricted by ipfw. Similarly, use of secure levels would allow us to > significantly reduce the effects of any kind of compromise. > > Some other thoughts I had were instructions for rolling a custom system CD > + possibly a boot disk to create read-only machines for use as proxy > servers or routers. Swap + MFS would be the only writable areas of the > system, and neither of those would persist over boot. > > On my multi-user machines, I know directly or indirectly many of the > users. But in the real world, contrary to the suggestions of many, one > cannot trust Joe User. Either because they don't take precautions > necessary to secure their own accounts, or because of the scale of the > environment. A number of the large scale UNIX machines I have seen go so > far as to disable all setuid utilities (other than su) to prevent > unauthorized use of the system. Including utilities such as ping. No one > debates the usefulness of remote login -- something that NT has as yet > been unable to provide at any reasonable cost. But in a less trusted > environment, it may be our undoing :). > > Anyhow, if there is sufficient interest in the project, I'd like to try > and get it off the ground. Presumably, some changes might work their way > back into the default distribution. If we lose no significant > functionality, it cannot hurt to restrict priveledges. It may help us > when those unpredicted vulnerabilities do turn up. > > Robert N Watson > > > ---- > Carnegie Mellon University http://www.cmu.edu/ > Trusted Information Systems http://www.tis.com/ > SafePort Network Services http://www.safeport.com/ > robert@fledge.watson.org http://www.watson.org/~robert/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message