From owner-freebsd-security Fri Apr 17 01:57:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA11239 for freebsd-security-outgoing; Fri, 17 Apr 1998 01:57:28 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11233 for ; Fri, 17 Apr 1998 08:57:25 GMT (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id MAA06829; Fri, 17 Apr 1998 12:53:05 +0200 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id LAA17452; Fri, 17 Apr 1998 11:15:07 +0200 (CEST) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.7/8.8.5/prosa-1.1) id KAA12109; Fri, 17 Apr 1998 10:55:57 +0200 (CEST) Message-ID: <19980417105557.59439@deepo.prosa.dk> Date: Fri, 17 Apr 1998 10:55:57 +0200 From: Philippe Regnauld To: Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions References: <199804170519.WAA12540@burka.rdy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88e In-Reply-To: ; from Robert Watson on Fri, Apr 17, 1998 at 01:45:29AM -0400 X-Operating-System: FreeBSD 2.2.5-RELEASE i386 Organization: PROSA Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Robert Watson writes: > 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. I'm all for this, and would be willing to test it. While you're at it: - include the hardening to _removing_ certain syscalls from the kernel (see below) - you could use the "ugly" dialog lib. to make a nice menu selection (like the GS port) to enable/disable features: [ ] Standard (definition) [ ] Paranoid (definition) [ ] X-Files [X] Custom [ ] Make kernel unreadable to world :-) [X] Append-only /var ? [...] > 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 :). Yep. > 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. Suggestion: how difficult would it be to have ipfw(8) respect the securelevel to, for example, refuse to flush / alter the ipfw list ? i.e.: all mods have to be tested before the securelevel is raised, and once it is, only rebooting into single user on the console allows you to change the filters. > 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. We need write-protect notch on the hard-disks :-) > 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. Some off-the-shelf firewall packages, like BorderWare (based on BSDi) uses a dual-kernel approach: - an operational, network-aware kernel stripped of suspect system calls (particularly the *id stuff) - a fully functional "single-user" kernel with NO networking to do the maintenance. This is a tad straight-jacketed, but you get the idea (I hope). > 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. Better than a port: a separate set of tarballs in the dist: harden.aa harden.ab ... ? Anti-bloatists oblige. -- -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- «Pluto placed his bad dog at the entrance of Hades to keep the dead IN and the living OUT! The archetypical corporate firewall?» - S. Kelly Bootle, ("MYTHOLOGY", in Marutukku distrib) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message