Do away with entry filter
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
Quoted 33 lines · 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.
Quoted 7 lines
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
Quoted 8 lines
Thanks,
-Steve--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 3 lines · Linda Knippers
Quoted 1 line
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?
Quoted 1 line
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.
Quoted 2 lines
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
Quoted 5 lines · Steve Grubb
Quoted 2 lines · Linda Knippers
Quoted 1 line
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.
Quoted 3 lines
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?
Quoted 8 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 2 lines
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
Quoted 2 lines
-Steve
Quoted 5 lines · Linda Knippers
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
Quoted 9 lines · Steve Grubb
Quoted 5 lines · Linda Knippers
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
Quoted 2 lines
-Steve
Quoted 9 lines · Steve Grubb
Quoted 5 lines · Linda Knippers
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
Quoted 5 lines · Eric Paris
Quoted 2 lines
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.
Quoted 3 lines
/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
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
Quoted 42 lines · Steve Grubb
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