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