stripping secure servers (was Re: releases and stuff)

Bennett Todd bet at rahul.net
Mon Nov 15 15:34:46 PST 2004


2004-11-15T22:52:39 Archaic:
> [ Bennett yaks about servers without /bin/sh ]
> What about cgi scripts or system management scripts?

A system that's offering anything CGI needs exceptionally careful
scrutiny in any case, and if I were hoping to call the thing
"hardened" in any interesting sense the CGI would be locked up
entirely in a chroot jail. It'd also not be written in /bin/sh; if I
were writing it, it'd be in perl. Other folks have other tastes.

> Would it be sufficient to move sh to an unique location?

Depends on your goals. And a system hardened to mjr's recipe cannot
realistically offer the most highly ornate services; the recipe
really fits best when the services being offered do not themselves
depend on the real power of the Unix environment. Sure, you can
write a CGI program in C, but who'd want to? (maybe it's time for
me to look into CGI libs for C ...) A perl that's in a chroot jail
makes an attractive target for a springboard. A system with nothing
on it that's usable as a shell is harder for most folk to hack. A
system whose shell is hidden is also harder. As hard? Depends on
your assumptions. Can the attacker get at a backup, or a design doc,
or someone willing to be socially engineered into chatting about the
layout?

Bringing HLFS briefly into the discussion, I don't imagine in any
sense that this style of hardening would be anywhere near its focus;
any From Scratch plan focuses on dev tools. Servers without /bin/sh
would definitely be BHLFS. But perhaps the possibility would be
valuable to have in mind; when you want to do something like this,
things like Busybox and static linking (made much less painful by
uClibc) get real traction.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20041115/a1870880/attachment.sig>


More information about the hlfs-dev mailing list