Re: Hardening, (was Re: chroot useful?)

["Marcus J. Ranum" <mjr () nfr net>]

>  What are some of the binaries you deleted from your systems.

Beats me. :) The question is what binaries the system still needs.

As I said in my previous posting, most firewall vendors that claim
to have "hardened" the O/S are bulls***ing you. You'll see a
"hardened" O/S on a firewall that uses a stock Solaris sendmail,
for example...   :P    As a former firewall designer, I have to
confess that I never did anything *I* would consider "hardening"
the system -- more along the lines of "cleanup" or perhaps
"a new coat of paint."

> [...] I am trying to make a linux 3.30 with kernel 2.0.30 more secure
> than out of the box/net.  I installed an minimal system with just the things
> needed to boot and then re-compile the kernel for my system then added
> networking and that was it.

This is a good approach. Start from zero and build up from there.

I devised an approach for doing this, which I've never (yet) had
a chance to try. Unfortunately. I'm hoping I'll get a chance to do
it with a machine for NFR one of these days but my schedule
doesn't permit much technical work anymore. So, I'll just describe
what I thought I'd do to the list and see if it helps anyone.

What I figured I'd do is take a PC with 2 SCSI disks in external
enclosures. I'd install (let's say) BSDI on one disk and make the
second one bootable, then dump/restore mirror the software
onto the second. Now I have 2 disks that are identical, both
bootable if they were SCSI ID 0.

Write a script that does a find on the file tree of the first disk.
It generates a list of all the files that are on the first disk. It
also generates a list of all the files that are NOT on the first
disk that are on the second disk. These files get checkpointed
to a directory on the second disk (the program should live
there too!) -- number the checkpoints automatically whenever
you run one.

Then you write a script that can revert the first disk to any
specified checkpoint. That way when you screw things up
real bad you just run "revert" and are back to the previous
checkpoint. For extra credit you could make it smart about
files that have been moved. Ideally I'd want to put everything
in "/" and zap the normal directory structure. Security through
incompatibility is a highly effective technique.

Now pour a pot of coffee and start tearing things up. Reboot
periodically. When something breaks, revert, fix, and then
checkpoint. Continue. Initial zaps would be broad-brush
(man pages, /usr/contrib, etc...) eventually things would get
more detailed.

When you're done you can take the script and generate
a list of all the stuff you deleted. Sort the list and recall
which deletions were complete directories -- compress
those out. Then you turn it into a script you can run which
will delete and move files all over the system. It becomes
your baseline for "re-zapping" each new release of the
O/S when it comes out.

The second alternative, which is probably better, is to
make 2 bootable disks, and zap EVERYTHING off one
except the kernel and init. Then start putting things back
one at a time. Note -- for those of you who are not already
UNIX gurus, you will be by the time you're done this
process.:)   [I think I could probably still pull it off but
UNIXes have gotten complex enough that it's no longer
something I'd tackle with a smile on my face]

Once you've minimized the system binaries (I dare not
call this "hardening") then it's time to tackle the fun
stuff like revamping the systems permission model.
Turn all setuid bits off. Then modify init so it setuids
to a non-root user immediately. Now there is no
privileged processing taking place at all. Everything
will break violently. You'll need to write little C programs
that do things like mount(2) necessary filesystems.
Delete the mount(1) command. Some programs maybe
need to be setuid root to start up. Hack their code to
immediately setuid to a non-root user. Then, if you're
inclined, play kernel games:
        -> whack the kernel so that files with the execute
        bit cannot be altered, renamed, or deleted when the
        system is running multi-user
        -> whack the kernel so that the execute bit cannot
        be set on files when the system is running multi-user
        -> whack the kernel so that you cannot use mknod(2)
        when the system is running multi-user
        -> whack the kernel so that attempts to execute
        instructions in the stack space halt the system
        and flag what program the buffer overrun was in.
        then fix the !*#@&! gnu C library.

I figure this is about a week's work for a UNIX guru to
do, and by the time you're done I'd say you'd have a
"hardened" O/S for a firewall.

mjr.
--
Marcus J. Ranum, CEO, Network Flight Recorder, Inc.
work - http://www.nfr.net
home - http://www.clark.net/pub/mjr