Securing FreeBSD 2.1.7.1

[tqbf () secnet com]

> I am thinking on "hardening" FreeBSD 2.1.7.1 system to run a firewall on
> top of it..

A few comments.

First of all, FreeBSD 2.1.7.1 is an old kernel. You'd be better off
working in 2.2. Lots has changed since 2.1, and 2.2 receives more
attention. It's also faster and supports more hardware.

Next, if your interest in hardening FreeBSD goes into the kernel, you
might be interested in knowing that lots of people, including many of the
core programmers of the OpenBSD project, are doing similar work. If you're
actually thinking of writing code (as opposed to, say, telling other
people how to write code =]), there's a mailing list called "bsd-harden"
you can subscribe to at majordomo () lists enteract com.

Finally:

> by implementing "securelevel 3"

Securelevels are evil. If you're hardening a kernel for a firewall, you
want it to boot up immutably secure. "Securelevels" are a convenience for
multi-user systems.

> with some system calls
> disabled/wrapped - like mount, mknod.. what else?

This is the type of work I've been doing; IMO, if you don't want to think
too hard about it, the best way to handle this is to take ALL the system
calls and allow them to be turned off.

Some things I (for example) have done:

        - Added a sysctl table of system calls allowable from within
          chroot(), which isn't changeable from within chroot() 
          [ big win: no process manipulation calls, so you can't escape
            chroot by hypnotizing other processes ]

        - Added a sysctl table of system calls allowed systemwide, 
          period, which can't be reverted (in the same evil, sick manner
          as securelevel). There are things like "ptrace" which I will
          never be comfortable with. =)

        - Added the capability to give an arbitrary process (or tree
          of processes) their own system call table, letting a program
          disable system calls at arbitrary points in the code, and
          allowing me to implement wrappers over things like open()

        - "trusted path execution" - execve only honors exec bit on
          programs in certain directories

Other people have done things like added modloadable wrapper calls for
arbitrary system calls or done crypto binary signing (as opposed to
trusted path). 

I don't know what the ideal restrictions for a firewalled OS would be, but
I'd be interested in hearing what other people think, because it would
give me other things to hack up in my kernel. =)

-----------------------------------------------------------------------------
Thomas H. Ptacek                                        Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.enteract.com/~tqbf                           "mmm... sacrilicious"