Re: Securing a Linux Firewall

["Marcus J. Ranum" <mjr () ranum com>]

John McDermott wrote:
> BTW, Marcus once wrote about an idea of creating a firewall by starting
> with a kernel and just a few basic utilities and then *adding* only the
> necessary software (as opposed to removing the unnecessary).  While I
> have yet to try this, it sounds difficult but probably more secure to me.


That's how I built the NFR CD-ROM boot mechanism. It only took me
4 days of fiddling to get a completely functioning environment for
my application, including rewriting my own cover of init(1) that
knew how to auto-format and put filesystems on uninitialized disks,
etc. All executables were statically linked. There was no /bin. There
was a /dev but it only had the SCSI and IDE disk entries, null, and
a copy of /dev/kmem with a driver that was modified to halt the
kernel if anything ever tried to write to it. To tell the truth, the
hardest part of the process was getting cdrecord to build on OpenBSD
(and that wasn't very hard). The only non-internally developed bits
of code on the machine were fsck and newfs (who wants to rewrite _those_)
I didn't even bother doing anything fancy with the immutable bit
on critical files - but I put a few bits of stuff in the kernel that
would tell me about unexplained chroots or other weird crossings
of permission boundaries. I wanted to hardwire certain special cases
of exec but never got around to it.

The boot logic was twisted in a fun sort of way:
1) boot from CD into mini floppy-root
2) init running probes hard disks; if SCSI or IDE disk with
        correct partition layout is found, use that
        (else: if disk found without correct layout, walk user
        through initializing with newfs; code to write disk label
        invoked directly out of init)
3) fsck selected disk
4) mount selected disk
5) chroot to selected disk
6) run within remaining environment

There were possible fun things that could have been done to
further reduce privs following the chroot but I figured that
the environment was tight enough. I think it used something
like 10Mb of the CDROM. And, not to mention, without all those
goofy rc-scripts it was mighty quick...

After I turned it over to my engineering team for further development,
I had to be pretty dogmatic to keep copies of the shell or perl
from infecting my nice clean base environment. ;) It _was_ hard to
hold the line on "no command interpreters" and I got tired of
explaining that perl was a command interpreter (albeit an ugly one)...

We never had a reported break-in in the CDROM environment. Period.
Of course I've been burned in the past - someone added 3rd party
code to my Gauntlet firewall after I left TIS - and it opened a
hole. So I've got a _justification_ for my insanity.

mjr.
---
Marcus J. Ranum                         http://www.ranum.com
Computer and Communications Security    mjr () ranum com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards