Re: Locking Down a Linux Box

From: Scott Gifford (sgifford@suspectclass.com)
Date: 01/03/02 

To: Jeff Schaller <schaller@freeshell.org>
From: Scott Gifford <sgifford@suspectclass.com>
Date: 03 Jan 2002 14:19:44 -0500

Jeff Schaller <schaller@freeshell.org> writes:

[...]

> So, I like imagining this setup against various attack scenarios,
> such as the interesting example put forward by Kurt a few posts ago
> where the attack mounts another filesystem over the top of one of
> yours. In Jeff's half-baked plan, that wouldn't be possible because
> the mount program is gone. There'd be no compiler, or even room to
> upload a compiled binary. (A /tmp directory is created with the
> minimum amount of space needed for temporary stuff durnig bootup).

It makes it slightly more difficult, and a bit less convenient, but
certainly not impossible. mount is a system call, and there are
dozens of ways to cause it to be executed---use Perl, compile mount(1)
elsewhere and copy it onto the system, etc. Lack of room could be
worked around by removing stuff. If the media is physically read-only
and noplace allows writing, it helps, but a skilled cracker could use
a buffer overflow or write to /dev/mem or /dev/kmem to cause code to
execute.

Every hurdle helps keep the bad guys out, bug "wouldn't be possible"
are pretty strong words in the security world. :-)

-----ScottG.

Quantcast