Robert van der Meulen <firstname.lastname@example.org> writes:
> Quoting Michael Stone (email@example.com):
> > [...] This task-harden package is degenerating farther and farther
> > from any sensible, useful tool and rapidly becoming a marginal
> > utility that will never get much exposure. I suggest starting
> > from the beginning, drafting some formal *goals* for the project,
> > and approaching this with a bit more flexibility so that it's
> > actually useful.
> Hear, hear! :)
I second that.
> 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, 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.
> The installation of the task-harden package could give hints to how
> to find out what you might _consider_ to install or deinstall, if
> you want to be secure in that area. (' you have 'rsh-server'
> installed, this might not be a good idea because <rant> - do you
> want me to remove it? ')
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.
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.
Ignore^WEnlighten me if I don't make sense ;-)
Olaf Meeuwissen Epson Kowa Corporation, Research and Development
Science is like sex: sometimes something useful comes out, but that is
not the reason we are doing it -- Richard Feynman