[RFC] Do away with entry filter

[RFC] Do away with entry filter

[Steve Grubb]

Hello,

I will be forking the user space audit code soon to start the next major 
series. I have a couple thoughts I'd like to share with people to see what 
they think.

The first item is doing away with the entry filter for syscall auditing. You 
normally run across this filter when you write rules such as:

-a always,entry -S open

The reason I think we can do away with it is that its purpose has changed. Way 
back in the early days 2.6.6 -> 2.6.15 kernels, there was this notion that 
the audit code could be made to have little impact on the performance of the 
system if we give hints about what is needed by using "possible" actions.

The problem with "possible" was that people forgot to use it and had exit 
filter rules that had no data to operate on. So, we changed the kernel to 
always collect the data it needed in case an exit filter would trigger an 
event. This was optimized and performance was pretty good. So, that kind of 
left the entry filter without a purpose. 

Any entry rule can be written as an exit rule. But not every exit rule can be 
written as an entry rule. So the logical choice is to consolidate on the exit 
filter. The reason to do this is to improve performance. If we have an entry 
rule that triggers, it marks the syscall excursion as auditable. When we get 
to the exit filter, it iterates over the whole set of rules even though the 
event is auditable. This is because there could be a never rule that would 
suppress the output. Another problem introduced by having two filters is that 
some fields are not available in the entry filter (exit for example), it adds 
complexity in the auditctl program and the in-kernel rule parser to look for 
these errors.

The way that we could make the change is for the audit package to silently 
convert entry rules to exit in user space. It could output a warning that 
entry rules are being converted and the admin should make the necessary 
adjustments. Then after some time has elapsed so that distros have all 
updated, drop support in the kernel for the entry filter.

Let's discuss...

Thanks,
-Steve

Re: [RFC] Do away with entry filter

[Linda Knippers]

Steve Grubb wrote:
> Hello,
> 
> I will be forking the user space audit code soon to start the next major 
> series. I have a couple thoughts I'd like to share with people to see what 
> they think.
> 
> The first item is doing away with the entry filter for syscall auditing. You 
> normally run across this filter when you write rules such as:
> 
> -a always,entry -S open
> 
> The reason I think we can do away with it is that its purpose has changed. Way 
> back in the early days 2.6.6 -> 2.6.15 kernels, there was this notion that 
> the audit code could be made to have little impact on the performance of the 
> system if we give hints about what is needed by using "possible" actions.
> 
> The problem with "possible" was that people forgot to use it and had exit 
> filter rules that had no data to operate on. So, we changed the kernel to 
> always collect the data it needed in case an exit filter would trigger an 
> event. This was optimized and performance was pretty good. So, that kind of 
> left the entry filter without a purpose. 
> 
> Any entry rule can be written as an exit rule. But not every exit rule can be 
> written as an entry rule. So the logical choice is to consolidate on the exit 
> filter. The reason to do this is to improve performance. If we have an entry 
> rule that triggers, it marks the syscall excursion as auditable. When we get 
> to the exit filter, it iterates over the whole set of rules even though the 
> event is auditable. This is because there could be a never rule that would 
> suppress the output. Another problem introduced by having two filters is that 
> some fields are not available in the entry filter (exit for example), it adds 
> complexity in the auditctl program and the in-kernel rule parser to look for 
> these errors.
> 
> The way that we could make the change is for the audit package to silently 
> convert entry rules to exit in user space. It could output a warning that 
> entry rules are being converted and the admin should make the necessary 
> adjustments. Then after some time has elapsed so that distros have all 
> updated, drop support in the kernel for the entry filter.
> 
> Let's discuss...

Without "entry", does "exit" still make sense?  In other words, are the
choices really just "always" and "never"?  If we're going to change
things, is this an opportunity to simplify in general?

-- ljk


> 
> Thanks,
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: [RFC] Do away with entry filter

[Steve Grubb]

On Friday 27 February 2009 11:56:57 am Linda Knippers wrote:
> > Let's discuss...
>
> Without "entry", does "exit" still make sense?

You mean the name? I think so for a compatibility perspective. Not everyone 
will change their rules right away. Are you suggesting to rename the exit 
filter to something more generic?


> In other words, are the choices really just "always" and "never"?

For syscall, yes. There are still task, exclude, and user filters. Of these, I 
can't think of any use for the task filter anymore either. I think at one 
time it, too, was envisioned to help select the right tasks for auditing. 


> If we're going to change things, is this an opportunity to simplify in
> general? 

I wouldn't mind losing task filter, too. But I was thinking mostly of the case 
where entry rules identify a syscal is auditable and then the exit filter is 
99% of the time walked in its entirety before deciding nothing to do.

-Steve

Re: [RFC] Do away with entry filter

[Linda Knippers]

Steve Grubb wrote:
> On Friday 27 February 2009 11:56:57 am Linda Knippers wrote:
>>> Let's discuss...
>> Without "entry", does "exit" still make sense?
> 
> You mean the name? I think so for a compatibility perspective. 

If you're going to change things and go through a transition
phase, you might as well change everything.

> Not everyone 
> will change their rules right away. Are you suggesting to rename the exit 
> filter to something more generic?

I'm suggesting changing the name to something that makes a little
more sense, or doing away with it if it isn't necessary for syscalls
anymore.  I'm assuming that's the case because there's no need to
distinguish it from "entry", so could we just drop "exit" and
ignore it (silently or otherwise) in the transition?

> 
>> In other words, are the choices really just "always" and "never"?
> 
> For syscall, yes. There are still task, exclude, and user filters. Of these, I 
> can't think of any use for the task filter anymore either. I think at one 
> time it, too, was envisioned to help select the right tasks for auditing. 
> 
> 
>> If we're going to change things, is this an opportunity to simplify in
>> general? 
> 
> I wouldn't mind losing task filter, too. But I was thinking mostly of the case 
> where entry rules identify a syscal is auditable and then the exit filter is 
> 99% of the time walked in its entirety before deciding nothing to do.

Ok - still makes me think we could drop both "entry" and "exit" and
just have "always" and "never".

-- ljk
> 
> -Steve

Re: [RFC] Do away with entry filter

[Steve Grubb]

On Friday 27 February 2009 12:48:30 pm Linda Knippers wrote:
> I'm suggesting changing the name to something that makes a little
> more sense, or doing away with it if it isn't necessary for syscalls
> anymore.  I'm assuming that's the case because there's no need to
> distinguish it from "entry", so could we just drop "exit" and
> ignore it (silently or otherwise) in the transition?

We still have user, task, and exclude filters. So we still need to be able to 
specify them.

-Steve

Re: [RFC] Do away with entry filter

[Linda Knippers]

Steve Grubb wrote:
> On Friday 27 February 2009 12:48:30 pm Linda Knippers wrote:
>> I'm suggesting changing the name to something that makes a little
>> more sense, or doing away with it if it isn't necessary for syscalls
>> anymore.  I'm assuming that's the case because there's no need to
>> distinguish it from "entry", so could we just drop "exit" and
>> ignore it (silently or otherwise) in the transition?
> 
> We still have user, task, and exclude filters. So we still need to be able to 
> specify them.

Sure, I'm only talking about the options that apply to syscalls.
If we don't need "entry" because we're going to make everything
work like "exit", then it seems like we don't need "exit" either.

-- ljk
> 
> -Steve

Re: [RFC] Do away with entry filter

[Eric Paris]

On Fri, 2009-02-27 at 13:19 -0500, Steve Grubb wrote:
> On Friday 27 February 2009 12:48:30 pm Linda Knippers wrote:
> > I'm suggesting changing the name to something that makes a little
> > more sense, or doing away with it if it isn't necessary for syscalls
> > anymore.  I'm assuming that's the case because there's no need to
> > distinguish it from "entry", so could we just drop "exit" and
> > ignore it (silently or otherwise) in the transition?
> 
> We still have user, task, and exclude filters. So we still need to be able to 
> specify them.

right, so lets call them   user, task, exclude and SYSCALL rather than
user, task, exclude and EXIT.

/me will very happily mark the old rule format, entry, and task lists
for kernel removal.  Maybe around 2.6.31? .32? I could clean all the
crap out.

-Eric

Re: [RFC] Do away with entry filter

[Steve Grubb]

On Friday 27 February 2009 03:14:04 pm Eric Paris wrote:
> > We still have user, task, and exclude filters. So we still need to be
> > able to specify them.
>
> right, so lets call them   user, task, exclude and SYSCALL rather than
> user, task, exclude and EXIT.

Precisely what I was trying to get at with Linda's comments. We still have to 
have the same rule format since you have to specify which filter the never or 
always goes with. And I would have to honor entry/exit inside auditctl for 
quite a while before dropping it there. But we should be careful about 
changing defines in the kernel.


> /me will very happily mark the old rule format, entry, and task lists
> for kernel removal.  Maybe around 2.6.31? .32? I could clean all the
> crap out.

Yes, I think we could give it a good cleaning out in the near future. I'd 
prefer having a patch soonish, but not submitted for a while so that distros 
can switch user space well before the kernel changes.

Additionally, I want to use the 2.0 release to clean out the legacy 
workarounds for defines at various points in the audit system's life.

-Steve

Re: [RFC] Do away with entry filter

[Steve Grubb]

Hello,

Just as a reminder to everyone, this proposal has been put in svn trunk as 
commit #300. I hope to have audit 2.0 out later this week.

-Steve

On Friday 27 February 2009 09:54:11 am Steve Grubb wrote:
> I will be forking the user space audit code soon to start the next major
> series. I have a couple thoughts I'd like to share with people to see what
> they think.
>
> The first item is doing away with the entry filter for syscall auditing.
> You normally run across this filter when you write rules such as:
>
> -a always,entry -S open
>
> The reason I think we can do away with it is that its purpose has changed.
> Way back in the early days 2.6.6 -> 2.6.15 kernels, there was this notion
> that the audit code could be made to have little impact on the performance
> of the system if we give hints about what is needed by using "possible"
> actions.
>
> The problem with "possible" was that people forgot to use it and had exit
> filter rules that had no data to operate on. So, we changed the kernel to
> always collect the data it needed in case an exit filter would trigger an
> event. This was optimized and performance was pretty good. So, that kind of
> left the entry filter without a purpose.
>
> Any entry rule can be written as an exit rule. But not every exit rule can
> be written as an entry rule. So the logical choice is to consolidate on the
> exit filter. The reason to do this is to improve performance. If we have an
> entry rule that triggers, it marks the syscall excursion as auditable. When
> we get to the exit filter, it iterates over the whole set of rules even
> though the event is auditable. This is because there could be a never rule
> that would suppress the output. Another problem introduced by having two
> filters is that some fields are not available in the entry filter (exit for
> example), it adds complexity in the auditctl program and the in-kernel rule
> parser to look for these errors.
>
> The way that we could make the change is for the audit package to silently
> convert entry rules to exit in user space. It could output a warning that
> entry rules are being converted and the admin should make the necessary
> adjustments. Then after some time has elapsed so that distros have all
> updated, drop support in the kernel for the entry filter.
>
> Let's discuss...
>
> Thanks,
> -Steve