From: Miloslav Trmac <mitr@redhat.com>
To: linux-audit <linux-audit@redhat.com>
Cc: juro <juro.fit@gmail.com>
Subject: Reactive rules (from juro.fit@gmail.com)
Date: Wed, 19 Aug 2009 03:12:05 -0400 (EDT) [thread overview]
Message-ID: <1056392541.1213981250665925854.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> (raw)
In-Reply-To: <a1e54a1c0908181508t7efd3b1aub920a4b6750ae74e@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2025 bytes --]
I planned to create a plugin which would extend the current audit
capabilities adding a new type of rule - a reactive rule. This
type of rule is different in the way that it watches for an event
like an ordinary rule, however, when the event happens, it reacts
to that adding or deleting other rules. For example, there is
a reactive rule that watches for a certain user to login and as
the reaction to the event, it adds the new rule that watches for
file changes in the user's home dir.
The problem with the plugin is that it would have to analyze
every single message from the dispatcher, parse it and look for
an appropriate rule in a rule set that caused this message was
generated. The process of parsing every message isn't the right
thing to do because of overheat.
I suggest that a change should be done in the kernel. The events
are filtered in it so that there is no need parsing the messages
sent to the auditd and this solution wouldn't cause any increase
in the load of the system caused by auditing.
First of all, the syntax of the rules should be changed a bit to
include reactive rules. It could look like this:
rule1
rule2 {
rule2_1
rule2_2
}
rule3
When an event that rule2 watches for occurs, rule2_1 and rule2_2
will be added/removed to/from the rule set.
The change in the syntax means a change in auditctl.c. Also,
struct audit_rule_data needs to be altered to include some flag
that makes it possible to recognize between the types of rules
when passed to the kernel.
Furthermore, ordinary rules are added/removed to/from the rule
set as soon as the kernel receives a request from the user space.
>From the example above, rules rule2_1 and rule2_2 can't be
added/removed to/from the rule set immediately because an event
that matches rule2 must occur at first. Although, they must be
saved in the kernel, for example, they could be kept in a list
of type struct list_head and the associated reactive rule would
keep a reference to this list.
----------
[-- Attachment #1.2: Type: text/html, Size: 2337 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next parent reply other threads:[~2009-08-19 7:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a1e54a1c0908181508t7efd3b1aub920a4b6750ae74e@mail.gmail.com>
2009-08-19 7:12 ` Miloslav Trmac [this message]
2009-08-24 19:28 ` Reactive rules (from juro.fit@gmail.com) 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=1056392541.1213981250665925854.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com \
--to=mitr@redhat.com \
--cc=juro.fit@gmail.com \
--cc=linux-audit@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