Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Apr 1998 14:08:30 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Philippe Regnauld <regnauld@deepo.prosa.dk>
Cc:        freebsd-security@FreeBSD.ORG
Subject:   Re: kernel permissions
Message-ID:  <Pine.BSF.3.96.980417135650.8952I-100000@trojanhorse.pr.watson.org>
In-Reply-To: <19980417105557.59439@deepo.prosa.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Apr 1998, Philippe Regnauld wrote:

> > 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)
...
> 
> 	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.

I had been thinking along similar lines also.  Either in terms of a new
securelevel (3?) with much tighter restrictions than currently in place,
or through the hardening of existing securelevels.  It might be desirable
to have a fairly multi-stage boot:

(secure level -1) (networking completely disabled)
check, mount file systems (non-network)
configure ipfw (do not enable it yet)
(secure level +1)
start common daemons that require append log file access (syslog)
(secure level +2)
start highest level daemons, but that might require a pid file
(secure level +3)
system is locked down, and network is enabled

I have not thought this out in detail yet.  However, ipfw modifications +
ifconfig modifications could only be made at secure level -1 or +1 or
such.  At +3, networking could be enabled and disabled as a whole through
ifconfig (interface) up or via ipfw, but no policy or configuration could
be modified.

Other thoughts:

/var/run on mfs
/tmp, /var/tmp on mfs

Disable drive mounting/unmounting/remounting at +2 and above?

Also, are there any conclusions about how to lower the securelevel?  Some
systems have an arrangement whereby when you run level goes down (i.e.,
shutdown to single user mode), you can regain lower securelevels without
rebooting.  I had concerns about the killing of processes at shutdown not
working right, or that there might be ways around this, so was thinking
for myself that only rebooting would lower the securelevel.

Perhaps we should be assembling a wish-list somewhere as there does seem
to be a great deal of interest.  Unless someone feels moved to have it on
www.freebsd.org, I'll go ahead and stick up all the suggestions I've
received so far on my own server and post a URL later today.

  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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980417135650.8952I-100000>