Re: OS Hardening
On Tue, Dec 12, 2000 at 08:41:30PM -0500, S.Salman Ahmed wrote:
>
> >>>>> "AS" == Andres Salomon <dilinger@mp3revolution.net> writes:
> AS> Oh, I totally agree; this would have to be on a per-package
> AS> basis, however. Hence, it would rely on each maintainers
> AS> willingness to do so. For example, a chrooted bind (running as
> AS> user nobody or something) would be nice, but the bind maintainer
> AS> has refused (at least until bind 9.1 is released.. see bug
> AS> #50013). A debconf option would be ideal here; the trick is to
> AS> convince the maintainer to add it.
> AS>
>
> I was thinking more along the lines of install time profiles. Something
> along the lines of how Manrake supposedly does it (never tried it,
> probably should one of these days) where the user is given the choice of
> selecting a security profile from a predefined set.
>
> If it was done on a per-package basis, that would be nice too.
>
> --
> Salman Ahmed
> ssahmed AT pathcom DOT com
>
Mandrake does it using msec, which (imo) is more of an annoyance
than anything else. Basically, you have various security levels
(1 through 6, I believe; 1 being the least secure), that you can
set by running `msec <level>`. Unfortunately, 6 (or 5, I forget
how many levels exactly) is not nearly granular enough for security.
Level 3 (or 4) has a rather nice feature, whereby you're emailed
a status report nightly of: all world-writable files, open
ports, changes in port status from the previous night, etc. This
is great, if you're adminning the box remotely; but if you're local
all the shit that gets sent to you via email also gets scrolled to
the console. Also, it works by appending stuff to conf files;
if you've ever used RPM, you know what a pain it is during upgrades,
handling conf files. You're not prompted, like w/ dpkg, the
conf files are just silently handled. It might either blindly
overwrite them (I've had that happen numerous times, mostly w/
redhat), back up the original config file (mv /etc/syslog.conf
/etc/syslog.conf.rpmorig), or make the new config file
(/etc/syslog.conf.rpmnew). Thus, once you've upgraded a package,
you MUST check to make sure that it's using the correct config
files. msec settings, as well as your own, tend to get lost.
Blah. RPM rant tangent, sorry. Basically, msec sucks (no
offense to any mandrake fans/developers out there; mandrake
is my favorite non-debian distro). I don't believe this to
be msec's fault; it think it's simply trying to handle far
too much, by what should be handled each package individually.
Currently, _most_ secure, on a personal box, is far different
from most secure on a nameserver, which is far different from
most secure on a shellbox. You could have the user select
security levels, then select the function(s) of their particular
machine, but this sounds overly complicated for a task that
could simply be handled by a particular package.
What might be better is totally different (perhaps nonofficial)
debian packages.. Add
deb http://secure.foobar.org/debian-secure unstable main contrib
to your /etc/apt/sources.list, and it will override bind_8.2.2p7-1
with bind_8.2.2p7-1sec, which is the same package, only w/ security
features added (chrooted, etc). This would keep the basis bind
package from interfering w/ settings, and it would be simple
enough to implement simply by changing postinst...
--
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, rriggs@tesser.com
Reply to: