Re: Common (basic) security checks for a base installation? (was Re: Security notification script in Perl)
On 30-Dec-02, 05:16 (CST), Javier Fern?ndez-Sanguino Pe?a <jfs@computer.org> wrote:
> On Sun, Dec 29, 2002 at 03:31:55PM -0600, Steve Greenland wrote:
> Let's think first of how the replacement will be, shall we?
> Otherwise people might expect cron (or a basic installation of Debian) to
> do some tedious security checks for them and won't find out until they've
> been hitten hard because we "removed" this from cron.
> How is basic security checks going to be handled in sarge? I guess
> that's the big question. Steve, please do not remove this from cron (or at
> least don't let the changes go into testing) until we have a roadmap on how
> this should be done.
I'm not going to "remove" the checksecurity script, but simply split it
out from the cron package. There's a couple of different ways to go with
that:
1. New package "cron-checksecurity" (c-cs). The cron package would
Depend on c-cs in sarge (so that it gets brought in on upgrades),
and then be made completely independent (well, c-cs would depend on
cron|anacron) in the release after that. This is the conventional way
to split packages, so that functionality isn't lost on upgrades. The
problem is that many people dislike the checksecurity script, and are
going to complain about the dependecy (see the dpkg/dselect split for
examples). You folks who have the time, skills and interest to create a
better system could do so independently, perhaps urging the admin to set
CHECKSECURITY_DISABLE="TRUE" in /etc/checksecurity.conf so that we don't
have redundant checks going on.
2. New package "checksecurity" (cs), which the cron package, at
most, Suggests. I'd also have cron send/show a low-priority debconf
note on upgrades about the split, and it would be mentioned in both
Descriptions. While this allows people to lose checksecurity on
upgrades, I don't think the the current checksecurity is actually of
much value, nor do I believe that many users think so: I don't think
I've ever gotten a request to make any of the tests in checksecurity
more rigid[1]; most people simply want ways to disable it. (Of course,
most of those people are also unable to read the configuration file or
manpage and find the "CHECKSECURITY_DISABLE" parameter...) In this case,
I'd be happy to turn checksecurity over to someone else (Steve Kemp has
volunteered) for enhancment as you see fit. My only qualm is that I'd
expect the configuration file to change dramatically, making upgrades
someone problematic, but then dealing with that would be up to someone
else. :-)
I'd prefer 2), as it lets me bail out sooner, but 1) is the
more traditional way to go. Oh, and the point of renaming it
'cron-checksecurity" is to reserver the "checksecurity" package name
for whatever you folks come up with. On the other hand, I'm loathe to
rename the configuration file, because while dpkg handles[2] moving a
conffile from one package to another pretty cleanly, renaming conffiles
is complicated and fragile, particularly when moving to a new package at
the same time.
One thing is not an option: leaving the current checksecurity script
as part of the cron package. I'm tired of the whining about it, it's a
completely inappropriate combination, and it's got to go.
Regards,
Steve
[1] This is where one you folks looks back through 7 years of bug
reports to find a counter-example. Don't bother, I've been made wrong
before, and will be again: it's not that hard. :-)
[2] Or so my experiments have indicated. But if anyone knows of a
particular gotcha, speak up now, please.
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Reply to: