Re: Task-harden
Hi,
Sorry for the extensive quoting, but i think it's in context here.
Quoting Olaf Meeuwissen (olaf@epkowa.co.jp):
> Robert van der Meulen <rvdm@cistron.nl> writes:
> > I was thinking that it would be cool to have a (debconf?) frontend
> > that asks questions about _what_ you want to secure, and installs
> > the packages you need. A package harden-inetd for example, would
> > _keep_ inetd, but tighten things up. The debconf scripts for this
> > harden-inetd package could ask questions about how tight you want
> > your config to be.
> Call me dense but isn't that the job of the individual packages? I
> mean, shouldn't your harden-inetd really be part of the postinst of
> the various inetd packages out there?
Yes, in a perfect world it is. I would be very happy if inetd asks me if i
want any 'standard' services enabled, for example (i would be even more
happy if i could remove inetd without any hassle, but that's another
subject).
What my idea tries to do, is to move the security-related questions to
people who want to see (and answer) those.
If you want to 'harden' your system, people who have clear (and 'general')
ideas about how to harden a specific package, can go around and make a
harden-<package> package, mess with their config, give options to the user,
and allow security-minded folk to answer those questions, and automatically
configure stuff in a 'secure' manner.
A 'normal' user, who isn't that concerned with security, should be given a
reasonably secure (but workable) alternative. Hardening is possible
afterwards, using a harden-<package> package.
This means dupication of code, and a lot of organisational work to keep both
the harden-<package> and the <package> in sync, but it also takes the task
of having-to-have-a-'security configuration'-system for that package away
from the maintainer, _and_ keeps 'uninteresting' security-related questions
away from the average user (*take breath here*).
> Yes, this means code duplication but methinks it would be desirable
> and/or necessary for the inetd maintainers to discuss configuration
> issues anyway. Adding the hardening would be just another issue to
> discuss for them.
I agree, but see above. Adding security questions to all packages where it
would matter for me, would mean adding a lot of 'questions' to the
installation process, for a lot of packages, meaning a lot of work for a lot
of maintainers. Splitting the harden-stuff off of the package itself, allows
for security-minded developers to take the security for a 'normal' package
to the next level, without having to interfere with the package maintainer,
his policy, lazyness or ideas.
> Now here's an idea I like a lot better. As a first stab at hardening
> your system it goes over all the packages you have installed and sort
> of tells you why you maybe shouldn't install it from a security point
> of view and offers more secure alternatives (we'd need some consensus
> on that first though) if you really want that service. Next, it goes
> over your configuration and tells you all about the holes in there :-)
> This would be the hard part.
That would be hard indeed, especially if you're talking about custom
configurations ;) - giving advice about your configuration, and optionally
changing it was what i had in mind about the individual harden-<package>
packages.
> Back to that consensus part, I think it would not be a bad idea to try
> and rank alternative packages security-wise. That way the task-harden
> package has something to work with and we could go hunt down all those
> bad dependencies, something like "rshd | sshd" for example.
Agreed, it can give advice about 'bad security practice', alter things on
request, or remove stuff (all on request, or as a reaction on a
configuration question).
task-harden should not limit things, it should just help, keep security
related configuration choices for you, and update them when other packages
update.
Greets,
Robert
--
Linux Generation
<zarq> ik heb net al uitputtende sex gehad met mijn schaapjes
Reply to: