3 p.m.
RBACPP FAU_SEL.1 Selective Audit
The TSF shall be able to include or exclude auditable events from the
set of audited events based on the following attributes:
(a) Object identity, user identity, subject identity, host identity, and
***event type***
I'm currently working on a design for a patch to the audit userspace and
kernel subsystem that provides this functionality. Additionally, I'm
conducting this work in conjunction with trying to provide extended
support for operators (such as > and <), as these would be useful in
this context.
To give credit where due, Steve Grubb and I have discussed a some of
these items in off hand conversations recently. I'm collecting those
thoughts and others here for review.
--
USER_SPACE
From a user-experience perspective, we're trying to enable a user to
exclude messages of a certain type (or ranges of messages of particular
types). If you're unclear what types of messages are currently defined,
see include/linux/audit.h. Given extended support for ranges and
comparative operators, this should be extensible to other audit record
keys, such the user, subject, etc.
I'm suggesting the ability to add new rules via auditctl to a new list,
perhaps called "exclude". The proposed interface would look like:
Exclude messages of a specific type:
auditctl -a exclude,always -F "type=AUDIT_IPC"
Exclude messages within range:
auditctl -a exclude,always -F "type=AUDIT_SYSCALL..AUDIT_CWD"
Exclude messages using auditctl helper terms (ALL_DAEMON interpreted by
auditctl to be a range of 1200-1299 as specified in the audit.h header):
auditctl -a exclude,always -F "type=ALL_DAEMON"
Use multiple rules to exclude audit system command messages:
auditctl -a exclude,always -F "type<1100"
Also, the same form should be usable for other parameters as well, such
as uid, pid, etc.
auditctl -a exclude,always -F "uid<500"
auditctl -a exclude,always -F "pid=464"
I have written the code necessary to create an ordered, compressed list
of ranges of numbers that the kernel could very efficiently filter on.
Given some arbitrary number of ranges (as small as a singularity and as
large as the enumerated space), the code creates a list of upper and
lower bounds, however few are necessary to properly express the list of
ranges. For instance, given the user input ranges:
10-20, 5, 15-25, 23, 50
The algorithm will produce an optimized list:
5,5
10,25
50,50
This is a key, inexpensive operation to perform in user space that is
potentially a valuable gain kernel space. Memory requirements are
minimized, matches are found quickly, and the traversal is aborted as
soon as a range greater than the current value is encountered.
Note that I've also written the code necessary to remove individual
elements or ranges from an existing range, such that given our previous
range: (5, 10-25, 50), one chooses to remove 7, 13, 40-60 would result
in: (5, 10-12, 14-25). This is needed for the user's ability to prune
and modify existing rules.
--
KERNEL_SPACE
The kernel piece of this is pretty straightforward, actually... Near
the very top of audit_log_start(), we basically do something like:
if (unlikely(audit_exclude_type(type)))
return NULL;
Where audit_exclude_type() traverses our list of ranges looking for a
match, returning 1 if is to be excluded, 0 if no matches found.
Remember, this is ordered such that we can end the traversal as soon as
possible.
--
NETLINK
I'm nearly ready to post a patch, but I'm waiting on some consensus on
Steve's previous thread (New operators for rules). As of this posting,
there's no consensus yet on how we go about passing these values to/from
the kernel/userspace.
I'm trying to work within struct audit_rule.
struct audit_rule { /* for AUDIT_LIST, AUDIT_ADD, and AUDIT_DEL */
uint32_t flags; /* AUDIT_PER_{TASK,CALL}, AUDIT_PREPEND */
uint32_t action; /* AUDIT_NEVER, AUDIT_POSSIBLE, AUDIT_ALWAYS */
uint32_t field_count;
uint32_t mask[AUDIT_BITMASK_SIZE];
uint32_t fields[AUDIT_MAX_FIELDS];
uint32_t values[AUDIT_MAX_FIELDS];
};
There have been several propositions so far (utilize upper bits of
flags; utilize matching fields[]/values[] entries; hack in a zero-sized
array). If you have opinions on the conveyance of said operators,
please post to aforementioned thread.
Other comments on the design here proposed?
:-Dustin
1:25 p.m.
--
USER_SPACE
From a user-experience perspective, we're trying to enable a user to
exclude messages of a certain type (or ranges of messages of particular
types). If you're unclear what types of messages are currently defined,
see include/linux/audit.h. Given extended support for ranges and
comparative operators, this should be extensible to other audit record
keys, such the user, subject, etc.
I'm suggesting the ability to add new rules via auditctl to a new list,
perhaps called "exclude". The proposed interface would look like:
Exclude messages of a specific type:
auditctl -a exclude,always -F "type=AUDIT_IPC"
Exclude messages within range:
auditctl -a exclude,always -F "type=AUDIT_SYSCALL..AUDIT_CWD"
Exclude messages using auditctl helper terms (ALL_DAEMON interpreted by
auditctl to be a range of 1200-1299 as specified in the audit.h header):
auditctl -a exclude,always -F "type=ALL_DAEMON"
Use multiple rules to exclude audit system command messages:
auditctl -a exclude,always -F "type<1100"
Also, the same form should be usable for other parameters as well, such
as uid, pid, etc.
auditctl -a exclude,always -F "uid<500"
auditctl -a exclude,always -F "pid=464"
I like the new 'exclude' list idea.
We can currently select to never audit with the use of the action 'never'.
Such as "auditctl -a exit,never -F pid=464"
If we add an 'exclude' list then it seems like we would no longer need the
'never' action.
I think 'auditctl -a exclude,always -F pid=464' is less confusing than the
user having to figure out if they only need one or all of the following:
auditctl -a exit,never -F pid=464
auditctl -a entry,never -F pid=464
auditctl -a task,never -F pid=464
auditctl -a user,never -F pid=464
1:47 p.m.
On Monday 03 October 2005 14:25, Debora Velarde wrote:
We can currently select to never audit with the use of the action
'never'.
Such as "auditctl -a exit,never -F pid=464"
If we add an 'exclude' list then it seems like we would no longer need the
'never' action.
Never means do not create the context and do not collect any information.
Exclude means do not send this message type even though all the info was
collected.
For example, we may not want to see LSPP messages in a CAPP environment. So,
we could tell it to exclude those messages. Where something on the never list
will not even trigger fs watches.
They are different.
-Steve
8:18 a.m.
On Thu, Sep 29, 2005 at 03:00:31PM -0500, Dustin Kirkland wrote:
The TSF shall be able to include or exclude auditable events from
the
set of audited events based on the following attributes:
(a) Object identity, user identity, subject identity, host identity, and
***event type***
I'm currently working on a design for a patch to the audit userspace and
kernel subsystem that provides this functionality. Additionally, I'm
conducting this work in conjunction with trying to provide extended
support for operators (such as > and <), as these would be useful in
this context.
<snip>
I'm suggesting the ability to add new rules via auditctl to a new
list,
perhaps called "exclude". The proposed interface would look like:
Exclude messages of a specific type:
auditctl -a exclude,always -F "type=AUDIT_IPC"
I don't think the exclude list should be a filter list, for a couple
of reasons. The filter rules are designed to represent particular
system events. Audit message types don't have anything to do with
what's going on in the system. Additionally, you are only making use
of one of the three possible actions (always). The others don't make
any sense in this context. This is a good indication that this
feature is not what the filter lists were designed for.
KERNEL_SPACE
The kernel piece of this is pretty straightforward, actually... Near
the very top of audit_log_start(), we basically do something like:
if (unlikely(audit_exclude_type(type)))
return NULL;
Where audit_exclude_type() traverses our list of ranges looking for
a match, returning 1 if is to be excluded, 0 if no matches found.
Remember, this is ordered such that we can end the traversal as soon
as possible.
The cleanest implementation would be a bitmask of all audit message
types. Checking the bitmask would require a single operation to
determine whether or not to generate the log message. You could also
define additional constants to represent groups of messages, which
would remove the need to support ranges.
Amy
2:42 p.m.
On Thursday 06 October 2005 09:18, Amy Griffis wrote:
The filter rules are designed to represent particular system events.
Not really. Syscall entry could become any kind of event. It could trigger a
watch, syscall, or nothing at all.
Audit message types don't have anything to do with what's
going on in the
system. Additionally, you are only making use of one of the three possible
actions (always).
Right. Because we would always want to do this.
The others don't make any sense in this context. This is a good
indication
that this feature is not what the filter lists were designed for.
Actually, this is the easiest thing to do. We need to make code to implement >
< and range operators, so why not re-use that code? If we don't we will have
duplicate code doing filtering. Besides, we need to be able to insert, list,
and delete the filtering rules. So once again, this fits the pattern of a
filter list. We would have to duplicate all that code if we don't consider it
a filter.
> Where audit_exclude_type() traverses our list of ranges looking
for
> a match, returning 1 if is to be excluded, 0 if no matches found.
> Remember, this is ordered such that we can end the traversal as soon
> as possible.
The cleanest implementation would be a bitmask of all audit message
types.
Maybe so, but not extensible.
Checking the bitmask would require a single operation to
determine whether or not to generate the log message.
It would take more than one op. We'd need to convert from message number to
bit mask and then look it up. The message numbers range from 1000 to 2400 for
now. We would obviously have to do some fixing up to use a bit mask.
You could also define additional constants to represent groups of
messages,
which would remove the need to support ranges.
We want ranges anyways. What if you wanted to audit uid > 500. How would you
do it?
-Steve
10:56 a.m.
Dustin & Steve,
I'm sorry if my first explanation was unclear. Hopefully this email
will be more understandable.
On Thu, Oct 06, 2005 at 02:21:02PM -0500, Dustin Kirkland wrote:
> The cleanest implementation would be a bitmask of all audit
message
> types. Checking the bitmask would require a single operation to
> determine whether or not to generate the log message. You could also
> define additional constants to represent groups of messages, which
> would remove the need to support ranges.
Agreed that it would be simplest. But it's neither scalable nor
flexible. 32-bits or 64-bits just won't support very many different
types of messages. There's been some discussion on this list about
increasing the message blocks from the current 100 to something much
larger to allow particular vendors to create message types of their own.
Space constraints shouldn't be an issue. On second look, I think
providing the capability to suppress groups of messages is sufficient.
Most of the message types within a given block don't provide a
complete picture without their counterparts. When would an admin want
AUDIT_SYSCALL records logged without AUDIT_PATH records? If any
message types within a block make sense on their own, they could have
their own bit in the bitmask.
Based on the current header file plus Steve's recent posting of future
message blocks, I see a total of under 20. Several of these are
reserved for future use. Even with future development, we are not
approaching 64 bits.
On Thu, Oct 06, 2005 at 03:42:21PM -0400, Steve Grubb wrote:
On Thursday 06 October 2005 09:18, Amy Griffis wrote:
> The filter rules are designed to represent particular system events.
Not really. Syscall entry could become any kind of event. It could
trigger a watch, syscall, or nothing at all.
I don't understand what you are trying to say. The events described
by filter rules would occur whether or not audit was running. The
"event" you are referring to -- the generation of an audit record --
is something that is specific to the audit system. It would not occur
if there were no audit system. So we are talking about two different
things, and the concepts should not be mixed. What you are suggesting
is like adding filter rules to set the audit backlog and such.
> Audit message types don't have anything to do with
what's going on
> in the system. Additionally, you are only making use of one of
> the three possible actions (always).
Right. Because we would always want to do this.
> The others don't make any sense in this context. This is a good
> indication that this feature is not what the filter lists were
> designed for.
Actually, this is the easiest thing to do. We need to make code to
implement > < and range operators,
Adding a range concept to the filter rules improves performance by
requiring fewer rules to express an event. There is nothing requiring
a specific type of operator. These are all possible implementations.
so why not re-use that code?
It doesn't make sense to re-use code when the solution does not fit
the problem.
If we don't we will have duplicate code doing filtering.
Not if message suppression is implemented with a bitmask.
Besides, we need to be able to insert, list, and delete the
filtering rules. So once again, this fits the pattern of a filter
list. We would have to duplicate all that code if we don't consider
it a filter.
There could be a single setting determining which message types will
be output to the logs. At a minimum, this requires a set and a clear
operation.
> Checking the bitmask would require a single operation to
> determine whether or not to generate the log message.
It would take more than one op. We'd need to convert from message
number to bit mask and then look it up. The message numbers range
from 1000 to 2400 for now. We would obviously have to do some fixing
up to use a bit mask.
Each call to either audit_log or audit_log_start occurs from a point
at which we could determine the message group. So you could add a
message group parameter to audit_log and audit_log_start.
I don't think a lookup table would be any easier to maintain than two
well-commented blocks of #defines.
> You could also define additional constants to represent groups
of
> messages, which would remove the need to support ranges.
We want ranges anyways. What if you wanted to audit uid > 500. How
would you do it?
This should be a different code path. See:
https://www.redhat.com/archives/linux-audit/2005-October/msg00017.html
Amy
5:33 p.m.
Exclude messages within range:
auditctl -a exclude,always -F "type=AUDIT_SYSCALL..AUDIT_CWD"
While it think its handy to be able to specify multiple types
easily, supporting ranges like this doesn't seem like a good
idea to me. If new types are added in the future within the range,
an admin might be excluding more than intended without even knowing,
and if the values of these definitions ever change, the rule might
not even make sense.
Exclude messages using auditctl helper terms (ALL_DAEMON interpreted
by
auditctl to be a range of 1200-1299 as specified in the audit.h header):
auditctl -a exclude,always -F "type=ALL_DAEMON"
I like this approach better. Maybe you could have ALL_SYSCALL,
which includes AUDIT_SYSCALL, AUDIT_CWD, AUDIT_PATH, and whatever
else comes with syscall auditing, regardless of what the values are.
-- ljk
PS I'm still cleaning up a backlog of mail so my apologies if this
has already been discussed in mail I haven't read yet.
9:02 a.m.
On Friday 07 October 2005 18:33, Linda Knippers wrote:
> Exclude messages within range:
> auditctl -a exclude,always -F "type=AUDIT_SYSCALL..AUDIT_CWD"
While it think its handy to be able to specify multiple types
easily, supporting ranges like this doesn't seem like a good
idea to me. If new types are added in the future within the range,
an admin might be excluding more than intended without even knowing,
and if the values of these definitions ever change, the rule might
not even make sense.
And conversely, the admin can suppress the range even if new messages get
added. That seems desirable to me. A developer may want to suppress all
kernel AVC messages while passing user space originating ones.
The idea is to give the admin the flexibility to suppress as much or as little
as they want. This includes the ability to suppress by number since people
sometimes upgrade kernels but not user space tools.
> Exclude messages using auditctl helper terms (ALL_DAEMON
interpreted by
> auditctl to be a range of 1200-1299 as specified in the audit.h header):
> auditctl -a exclude,always -F "type=ALL_DAEMON"
I like this approach better.
But its the same thing. :)
The fact that it is expressing type=AUDIT_FIRST_DAEMON..AUDIT_LAST_DAEMON is
hidden from you.
Maybe you could have ALL_SYSCALL, which includes AUDIT_SYSCALL,
AUDIT_CWD,
AUDIT_PATH, and whatever else comes with syscall auditing, regardless of
what the values are.
One for each block of messages is planned.
-Steve
7011
days inactive
7023
days old
linux-audit@lists.linux-audit.osci.io
7 comments
5 participants
participants (5)
-
Amy Griffis -
Debora Velarde -
Dustin Kirkland -
Linda Knippers -
Steve Grubb