Quoting Michael Stone (email@example.com):
> That's their own problem, and a local security policy. 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! :)
Would a package that installs packages (or sets packages to 'install') be
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.
The flow would be 'install task-harden'; answer questions about _what_ to
harden, then exit (asking the user to re-run apt-get).
During the second apt run, the 'real' hardening takes place; each
harden- package asks specific questions about their part.
This whole scheme is based on the assumption that it would be possible to
add packages to the install-list _during_ the configuration of a package.
It would also be clumsy, as you have to run apt-get twice to get the full
I think 'harden-' packages should not contain binaries or Conflict: against
things; they should just 'tighten up', change settings, configure stuff in a
security-wise more sensible way.
There are too much packages to Conflict: with, and people are too different
to make a global package that has conflicts that suit everybody.
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? ')
If you want divine justice, die. -- Nick Seldon