[Logcheck-devel] Re: Logcheck rules from other packages

[Jamie L. Penman-Smithson]

[Forgot to Cc my reply to the list..]

On Fri, 2005-06-03 at 12:27 -0400, Todd Troxell wrote:
> I'm not sure if this message ever made it to you, Jamie.  I had a reverse DNS
> problem shortly after it was sent.

It did, eventually. :)

Hey Todd,

On Wed, 2005-06-01 at 01:22 -0400, Todd Troxell wrote:
> On Mon, May 30, 2005 at 09:57:32PM +0100, Jamie L. Penman-Smithson wrote:
> > I'm not so sure about the policy of handing over responsibility for
> > package specific rules to some maintainers is a good idea. For example,
> > there has been one or two bugs against the supplied logcheck rules with
> > packages which could have lead to vast amounts of messages being
> > ignored. If a script kiddy was attempting to break in to the system at
> > the same time, logcheck wouldn't have reported it.
> 
> Yeah, I'm not crazy about the idea of relying on rules from other maintainers
> either.  Maybe dh_installlogcheck could run some simple sanity checks on the
> rules from other packages before they are installed.

What happens if they fail to pass the sanity check? Other maintainers do
not care about logcheck rules as we do. They are secondary to the rest
of the package. Sometimes they're so badly written that they ignore
security sensitive messages.

If we're running sanity checks, what can we do about it? Not much. These
rules should be packaged with logcheck and have the same scrutiny that
all the other rules have.

The other issue that isn't being discussed is with a central logserver,
you might not have all the packages installed but you definitely want
all the rules for those packages installed.. Currently, if logcheck is
used on a central logserver all the rules from other packages need to be
installed (and updated) manually.

> An idea I've had in working on pylogcheck for dealing with this is somehting I
> was calling "directors"
> 
> Syslog message prefixes to the corresponding rule file, so lines like:
> 
> ^Jun  102:16:32 localhost dhcpd.*$
> 
> would be directed to (and processed only by the dhcpd rule file.)
> 
> Certainly there are complications with this, and I never actually planned to
> implement it in Logcheck proper, but it's something to think about, I guess.

In terms of security this addresses part of the problem, but doesn't
stop maintainers from adding rules that ignore problematic messages from
their own daemons.

> I'm not really sure how the policy change would go down...  I'd love to see
> some algorithms for sanitizing rules.  I am not sure how much of this is
> possible, but they would be useful in the future for web-based rule
> submission and whatnot.

With regard to web-based rule submission sanitizing the rules is going
to be a must. I just don't think it'll work with rules included from
other packages.

<snip> 
> > Another thing, if we have rules that are maintained by others (not the
> > logcheck team), we should make it crystal clear which rules are included
> > in logcheck and which rules are included in other packages. The bugs
> > filed against qpopper (that were three years old) were filed in the
> > wrong place, somehow we need to make it clearer that say, bugs in
> > qpopper logcheck rules should be filed against logcheck. Then again, if
> > we include the rules from other packages in logcheck again, this problem
> > will cease to exist.
> 
> Maybe add some docs to the tune of "please run dpkg -S $RULEFILE before
> submitting a bug."

I'll add that to README.logcheck-database, but I'm not sure that many
people will see it :)

-- 
-Jamie L. Penman-Smithson <jamie at silverdream.org>
 t: +44 1273 424795; f: +44 1273 424795
 PGP: C0A7 955E EED6 A309 23D7 863B C76A 26A3 F0DC FCA8
 never send mail to: oubliette.z at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20050604/8995a0c7/attachment.pgp