[RFC] Virtual Key Fields

[RFC] Virtual Key Fields

[Steve Grubb]

Hi,

Based on the discussion last week, I'd like to propose a technique of allowing 
the appearance of multiple key fields without having to make changes in the 
kernel. The kernel has one key field associated with each audit rule. It 
doesn't look at the field's contents for anything. A patch will be submitted 
for 2.6.26 kernel increasing the size of string the kernel will accept. The 
kernel will still allocate the minimum memory needed to hold the string.

If the admin wants to have multiple keys that can be searched on for different 
purposes, we will allow that from auditctl. A couple examples: a rule meets 
more that one requirement and he/she wants to document that separately, or 
there are interpretive plugins that would like some standard tagging of 
rules. To do this, auditctl will support multiple -k fields.

When reading the rule, auditctl will append multiple keyfields to one another 
with a non-printing separator. The value 0x01 is a good candidate since its 
not likely to be used by any admin right now. Auditctl will scan each key 
field and reject the key with a warning if the separator appears in a key 
field. The rule will be processed normally without the key, though.

When rules are listed, auditctl will split the keys out so they appear 
separately. This mimics the way the rules were written. Auditctl will also 
allow listing by key in order to aid rule analysis by the admin.

Auditctl will also allow delete all rules matching a key. This will allow the 
admin or a program to delete a set of rules related to just a particular key 
and leave all other rules intact.

auparse will split the key fields in audit records so that multiple key fields 
exist whenever it finds the separator in the key field in the event stream. 
The applications using keys should iterate over the keys to examine them all 
if its looking for something in particular.

Comments?

-Steve

Re: [RFC] Virtual Key Fields

[Eric Paris]

On Mon, 2008-03-24 at 09:27 -0400, Steve Grubb wrote:
> Hi,
> 
> Based on the discussion last week, I'd like to propose a technique of allowing 
> the appearance of multiple key fields without having to make changes in the 
> kernel. The kernel has one key field associated with each audit rule. It 
> doesn't look at the field's contents for anything. A patch will be submitted 
> for 2.6.26 kernel increasing the size of string the kernel will accept. The 
> kernel will still allocate the minimum memory needed to hold the string.

I really like it.  I think it is a good solution to the problem you were
trying to solve.


> Auditctl will also allow delete all rules matching a key. This will allow the 
> admin or a program to delete a set of rules related to just a particular key 
> and leave all other rules intact.

How does this work?  This is a completely new concept and it seems like
it should be a second patch after you have multiple keys in to start
with.

auditctl -a exit,always -w /tmp/file1 -k file1 -k shared-key
auditctl -a exit,always -w /tmp/file2 -k file2 -k shared-key

now if I say (and i'm just guessing your new syntax):

auditctl -d -k shared-key

what do I end up with?  no rules?  still 2 rules but without the -k
shared-key?

I really think this part of the proposal needs to be explained a whole
lot more before I buy into it.  I'm scared of trying to remove rules by
key and getting unanticipated results....

-Eric

Re: [RFC] Virtual Key Fields

[Steve Grubb]

On Monday 24 March 2008 09:42:14 Eric Paris wrote:
> > Auditctl will also allow delete all rules matching a key. This will allow
> > the admin or a program to delete a set of rules related to just a
> > particular key and leave all other rules intact.
>
> How does this work?  This is a completely new concept and it seems like
> it should be a second patch after you have multiple keys in to start
> with.

This is all in user space so no kernel changes are needed.


> auditctl -a exit,always -w /tmp/file1 -k file1 -k shared-key
> auditctl -a exit,always -w /tmp/file2 -k file2 -k shared-key
>
> now if I say (and i'm just guessing your new syntax):
>
> auditctl -d -k shared-key

I was only going to change the '-D' option (delete all). Assuming this was 
typed:

auditctl -D -k shared-key

You have no rules left which is the same as if you did not have the -k added. 
If however, you have this loaded:

-a exit,always -w /tmp/file1 -k file1 -k my-file-key -k ids-file-high
-a exit,always -w /tmp/file2 -k file2 -k another-key -k ids-file-high

auditctl -D -k another-key

will just delete the second rule.

auditctl -D -k ids-file-high

will delete them all.

-Steve

Re: [RFC] Virtual Key Fields

[Eric Paris]

On Mon, 2008-03-24 at 09:52 -0400, Steve Grubb wrote:
> On Monday 24 March 2008 09:42:14 Eric Paris wrote:
> > > Auditctl will also allow delete all rules matching a key. This will allow
> > > the admin or a program to delete a set of rules related to just a
> > > particular key and leave all other rules intact.
> >
> > How does this work?  This is a completely new concept and it seems like
> > it should be a second patch after you have multiple keys in to start
> > with.
> 
> This is all in user space so no kernel changes are needed.
> 
> 
> > auditctl -a exit,always -w /tmp/file1 -k file1 -k shared-key
> > auditctl -a exit,always -w /tmp/file2 -k file2 -k shared-key
> >
> > now if I say (and i'm just guessing your new syntax):
> >
> > auditctl -d -k shared-key
> 
> I was only going to change the '-D' option (delete all). Assuming this was 
> typed:

Ok, the fact that you only planned to do this with -D assuages all of my
fears.  Don't think it is strictly necessary in the first patch round,
but at least I'm not scared of it any more  :)

-Eric

Re: [RFC] Virtual Key Fields

[LC Bruzenak]

On Mon, 2008-03-24 at 09:27 -0400, Steve Grubb wrote:
> 
> Comments?
> 
Seems like a good plan to me.

LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: [RFC] Virtual Key Fields

[Klaus Heinrich Kiwi]

On Mon, 2008-03-24 at 09:27 -0400, Steve Grubb wrote:
> Comments?
> 
Looks very appropriate - thanks!

  -Klaus

-- 
Klaus Heinrich Kiwi
Security Development - IBM Linux Technology Center