From: Linda Knippers <linda.knippers@hp.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Linux Audit <linux-audit@redhat.com>, Valdis.Kletnieks@vt.edu
Subject: Re: [RFC] programmatic IDS routing
Date: Wed, 19 Mar 2008 15:55:23 -0400 [thread overview]
Message-ID: <47E16FAB.4010601@hp.com> (raw)
In-Reply-To: <200803191528.55805.sgrubb@redhat.com>
Steve Grubb wrote:
> On Wednesday 19 March 2008 15:04:57 Linda Knippers wrote:
>> I'm not sure why all of the above apply.
>
> Because this IDS is part of the audit system.
Is there something that describes what you're building so we can
have the right context to comment on this? I assumed you were
building something that would be a dispatcher plug-in or something
rather than building something new into the core audit subsystem.
>> If an IDS has a dependency on audit and specific audit rules to get the
>> information it needs, it can use the information in its config file to
>> construct the audit rules it needs.
>
> Then you surely have duplicate rules controlled by 2 systems. The first rule
> in the audit.rules file is -D which would delete not only the audit event
> rules for archival purposes, but any IDS placed rules. There is not a simple
> way of deleting the rules placed by auditctl vs the ones placed by the IDS.
> The IDS system would also need to be prodded to reload its set of rules
> again.
An IDS should be able to be prodded to reload its rules. And it should
do something if it sees audit being disabled. If someone wants IDS
functionality, they'd probably be using the IDS to manage the files
they're watching so I don't think you'd have IDS watches and separate
audit watches.
>
>> I don't think an IDS config file needs to be any more complicated than an
>> audit rules, and in fact should be simpler.
>
> I think it would be more complicated going down this path for a number of
> reasons.
To me it seems more complicated to bundle everything together and
overload the key.
-- ljk
>
> -Steve
next prev parent reply other threads:[~2008-03-19 19:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 17:02 [RFC] programmatic IDS routing Steve Grubb
2008-03-19 17:12 ` Linda Knippers
2008-03-19 17:40 ` Steve Grubb
2008-03-19 17:55 ` Steve Grubb
2008-03-19 18:18 ` Valdis.Kletnieks
2008-03-19 18:54 ` Steve Grubb
2008-03-19 20:09 ` Valdis.Kletnieks
2008-03-19 18:05 ` Valdis.Kletnieks
2008-03-19 18:40 ` Steve Grubb
2008-03-19 19:04 ` Linda Knippers
2008-03-19 19:28 ` Steve Grubb
2008-03-19 19:48 ` Eric Paris
2008-03-19 20:48 ` Steve Grubb
2008-03-19 19:55 ` Linda Knippers [this message]
2008-03-19 21:01 ` Steve Grubb
2008-03-19 21:31 ` Linda Knippers
2008-03-19 21:41 ` Eric Paris
2008-03-19 22:42 ` Steve Grubb
2008-03-19 23:00 ` Linda Knippers
2008-03-19 23:44 ` Steve Grubb
2008-03-20 13:32 ` Linda Knippers
2008-03-20 13:53 ` Steve Grubb
2008-03-21 10:28 ` Klaus Heinrich Kiwi
2008-03-21 12:50 ` Steve Grubb
2008-03-21 14:14 ` LC Bruzenak
2008-03-21 15:01 ` Steve Grubb
2008-03-21 16:32 ` LC Bruzenak
2008-03-24 13:13 ` Klaus Heinrich Kiwi
2008-03-20 12:19 ` Steve Grubb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E16FAB.4010601@hp.com \
--to=linda.knippers@hp.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox