Re: Locking Down a Linux Box

From: Mark Tinberg (tinberg@securepipe.com)
Date: 01/10/02


Date: Wed, 9 Jan 2002 22:34:11 -0600 (CST)
From: Mark Tinberg <tinberg@securepipe.com>
To: Jeff Schaller <schaller@freeshell.org>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 8 Jan 2002, Jeff Schaller wrote:

> manages to get shell access, they will have a hard time making
> changes. This idea extends to buffer overflow asm code, etc.
> Initially, there would be no network-aware daemons on the box.
>

Which is where I would like to go back to my initial analysis (hopefully
more succinctly phrased this time). Without any network-aware daemons
running the only places where external, untrusted data is processed is in
the TCP/IP stack and possibly Syslog.

 * TCP/IP -- If an attacker is able to subvert the TCP/IP code in a way
   gives them control over the execution of the kernel, it's game-over.
   Whether or not userspace even exists is totally irrevelant, it doesn't
   effect to security of the total system in any way.

 * Syslog -- Log messages from the kernel may have externally controllable
   data (IP addresses, ports, flags, etc.) that show up in the logs. If
   you don't do any processing of the logs on the system and instead
   forward everything to the console/syslog server then you are limited
   to just the daemon. You can use regular permissions and chroot to make
   sure that all it has access to is /dev/{log,klog,console} and that it
   can send datagrams to your central server. There are more things you
   could do but particular problem isn't rocket science.

The only other way into the system would be the console, and not running a
getty will go a long way to making that unfeasable to break. Then all you
worry about is bootup security. In any event since these attacks will
require physical presence at the host they can be heavily mitigated by a
basic lock and key (and maybe an armed guard with a Dirty Harry complex).

I just don't want to see you expend extra effort in places that won't
matter. You have to look at the whole system, see where untrusted data is
processed and work from there. You could start with LFS and build up just
the system that you want without too much fuss.

- --
Mark Tinberg <MTinberg@securepipe.com>
Network Security Engineer, SecurePipe Inc.
Remember: Wherever you go, there you are!
Key fingerprint = AF6B 0294 EE33 D802 F7A1 38A4 CF52 5FE0 7470 E5F7

        Your daily fortune . . .

Women give themselves to God when the Devil wants nothing more to do with them.
                -- Arnould
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iEYEARECAAYFAjw9GcQACgkQz1Jf4HRw5feSqQCfTsSFEd+TkqhpNSvu0F3z5ln0
azkAnjUMp7xe/ZN8ecZeQw/0WiMfNxD+
=HBHH
-----END PGP SIGNATURE-----