[LWN Logo]

Date: Fri, 14 May 1999 18:13:27 +0200
From: Alexander Kjeldaas <astor@fast.no>
To: "J. Lasser" <jon@lasser.org>
Subject: Re: Secure Linux Distribution project

On Thu, May 13, 1999 at 04:05:35PM -0400, J. Lasser wrote:
>
> Right now, I'm looking for a few things:
> 
> 1.	A list of other folks who've secured Linux distributions in the
> 	past and would be interested in unifying their work with others.
> 	It seems that most folk who have done this (myself included) did
> 	a lot of installation-specific stuff that could likely be
> 	generalized to some extent.
> 
> 2.	A list of other similar projects we should be corresponding
> 	with. Also, sites with information on how to do this are good
> 	too.
> 
> 3.	Anyone who wants to be on our mailing list (not yet created,
> 	but will be soon.)
> 
> 4.	Anyone who would like a leadership role in the project. PLEASE
> 	don't say you do unless you're really serious about it -- we've
> 	got a rather tight timeline and I don't want to mess around.
> 
> 5.	General comments, pointers, and advice are always welcome.
> 
> 6.	Anyone with lots of experience with the Red Hat installer. :-)
> 
> 7.	Anyone who'd like (okay, like's a pretty strong word) to
> 	maintain some web pages for this.
>

Hello, this is very interesting.  I'd like to tell you about two
distributions that I've made that you've probably never heard about.
The first one is called GNSL and the other one is called Samsix.

The first one is a distribution that we made in the company I recently
worked for (we were bought) - called GNSL (www.guardian.no/gnsl/).
This distribution was based on Linux 2.0.  It was mostrly used for
firewall setups.  It included a lot of extra securelevel checks that
made the setup pretty "hardened".  Really, you couldn't do much -
almost all interesting system calls were disabled and the files were
immutable.

Then Andrew came along with the POSIX.6 patches to Linux 2.0 and I
took those and ported them to 2.1, and they were later included in
2.2.  I then started on a distribution that would rely on capabilities
instead of securelevel as a primary security mechanism.  Using
capabilities, it is clearly possible to make a more flexible
distribution.  Security is always a tradeoff, but with better tools
you can create a more flexible distribution while being able to have
the same level of confidence in the system.

This second system was made one year ago and was put in use around
August.  Samsix is still the only distribution I know of that has used
capabilities at all!  Today, Samsix is used for DNS, mail, web-server,
disk-server, and some experimental services like LDAP.

We made this distribution in cooperation with UNINETT which is a
Norwegian research organisation.  Their customers are Universities and
other educational institutions.


So I've been involved with building some secure Linux-distributions.
Because of that I have used a lot of time thinking about secure linux
distributions, and I'm positive about one thing - building on RedHat
is wrong.  This is if you want to make a secure _operating system_.
If you just want to provide crypto-packages or various improved stuff
(relay.com-domain), that's ok.  But when I'm talking secure _operating
system_ you want to change the system from beneath.  You want to:

  o Crypto support
     - In the kernel
     - IPsec & friends integrated.
     - Crypto in most applications
     - Swap to encrypted partitions
     - Boot from encrypted partitions (secure against physical theft)
     - Tag certain partitions as encrypted
     - Support smart-card readers, crypto-hardware.
  o Patch programs to use various improved mechanisms.
     - Secure logging/auditing,  better syslog
     - Use capabilities on daemons.
     - Support MAC, Auditing.
     - Modify libc in sorts of ways.
  o Hardened features
     - You need to be careful where files are put so that you can
       have most of the system mounted read-only.
     - Run with / read-only.
     - Use kernel-features that others might not want to use such as
       random PID and no-exec stack.
  o Packaging
     - Want to be able to require authenticated packages.
     - Have a package-system which knows whether the source was
       authenticated, where the patches came from etc.
  o Have different defaults on configuration files.
  o Have a system for caging processes
  o Strive for B1 compliance


So I'm pretty sure that a secure linux will have

  o Different packages 
	- because they contain crypto
  o Different config-files 
	- because the audience is different
  o Different startup-scripts 
	- because you want to support encrypted partitions, IPsec, VPN
  o Different kernel  
	- because you need a lot of extra features
  o Different libraries. 
	- because you use enhanced security features in the kernel or
      	  outside the kernel
	- because you use crypto
  o Different file-structure layout 
	- because you want to support read-only mounting of various
  	  file-systems

Also, consider that when a new distribution is born, there is an
opportunity of not being backwards-compatible.  For instance, a new
distribution doesn't have to be compatible with /etc/sysconfig/*, but
can support linuxconf directly.


astor

-- 
 Alexander Kjeldaas, Fast Search & Transfer, Trondheim, Norway