[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: New development
- From: Steve Grubb <sgrubb redhat com>
- To: Linux Audit Discussion <linux-audit redhat com>
- Subject: Re: New development
- Date: Mon, 12 Sep 2005 09:14:28 -0400
On Thursday 25 August 2005 13:55, Steve Grubb wrote:
> If you have ideas about nice things to add, lets start the discussion
I think its time to kick off the next round of development for the audit
system. I would like to propose a list of items to be worked on. This is list
does not include LSPP/RBAC...that topic is big enough for a message all its
own. I will send an email covering LSPP/RBAC separately in a couple days.
This list is by no means complete. It is a starting point for discussion. If
anyone else has ideas, please speak up.
1) Syscall auditing enhancements. Collect all args to execve. This would be
implemented as an aux record like the socket_addr type. As all items come
from userspace, they should all the treated as untrusted data. This might
also need to be expanded for ioctl syscall as well. Does anyone know of any
function that we need special handling to get its parameters? Also, would
collecting EIP that the syscall was made from be useful to anyone? This might
be useful to people doing IDS systems so they can spot an anomalous
EIP/syscall pair to know something has gone wrong.
2) Higher Performance. We need to work on ways to lessen the load when the
audit system is both disabled and enabled. I put some ideas on the mail list
last week. There are more things that can be done. Perhaps a hard look at the
organization of the context should be done. Are the structure members really
in the best locations for cache effects? Can we get rid of TIF_SYSCALL_AUDIT
flag and then successfully re-attach later? Maybe this can be done by walking
the process tree or hooking a specific function all programs execute to
re-enable. Another way to help performance is to push the decision to audit
out to where the hook function is located. Chris has shown that it can be
done using inline hook functions. Also, we should look at whether syscall
entry filter as implemented is optimal. Right now all syscalls are marked
like possible unless there is a rule explicitly saying to not audit the
syscall. I think this area needs review.
3) Ability to track child processes. There is a need to be able to audit the
actions of a child process. For example, maybe we add a rule to audit a
specific pid like apache's. We may need to collect all syscall data for any
child it spawns. This can be done by matching on session id, process group,
and/or another mechanism. I leave this as an "and" since all 3 things may
need to be implemented. Process group and session ID are not fool proof, but
work for any non-malicious program. If we want to consider tracking possibly
untrusted apps - we need to implement another mechanism.
4) More operators for filters. Right now, we only have == and !=. It would be
nice to write rules that could use >, >=, <, <=, and a range. For example,
you may want to write a rule that is filtered on uid >= 500 so that you don't
collect data for daemons. Does anyone have ideas on rules that are awkward to
express given the current techniques?
5) Ability to filter on message type. Because we are going to support LSPP and
CAPP, we need to filter this information in the kernel. All messages start
with a log_start. That function could call the filter to see if the message
should be allowed. If so proceed as done today. Otherwise leave a NULL
buffer. All calls to helper functions like log_format & log_end functions
would check for NULL and return as if they succeeded. The other way I see
this working is have the log_end function do the filtering, but that means
that all the helper functions did the full work of building the message
before it is discarded. The filter on message type would be one rule where we
would want to have a range operator. For example, we may want to block all
USER, LSPP, or SE Linux AVC messages.
6) Normalization of SE Linux AVC messages. Right now, SE Linux code has if
statements that swing in and out different fields in its messages. This
information needs normalizing as a step towards getting to binary message
format. This may need to be done as AUX records or changing from a generics
AVC message to several message types.
7) Consolidation of information in events. There is duplicate information in
various records emitted. We need to try to reduce that information and
consolidate. I think this involves reviewing the messages to make sure they
follow a standard pattern. A message printing function could be created so
that format specifiers are not all over the kernel, but in 1 place. This is a
necessary step for creating a binary format.
8) Binary format. We need to create a format where the data is handed to the
audit daemon in a binary format. This would avoid all the snprintf that is
currently done. If there is no audit daemon, then the kernel would use the
common messaging framework mention in #7 above to create the text message.
As for implementing these ideas...I think we need to start with the current
2.6.9-11 kernel. When U2 kernel is public, port the audit system to that and
continue. At some point, we need to switch to the rawhide kernel. The LSPP
work for example does not belong in the 2.6.9 series kernel.
What I would like to see get into the 2.6.9 series is #1 & #2. #3, #4, & #5
might be possible to get into the 2.6.9 series if we come up with a good way
to make sure old kernels don't panic or do something bad. #6, #7, & #8 would
definitely be for rawhide.
Let's discuss these points. Do they make sense? Are there more ideas that
should be added? Do the ones slated for 2.6.9 make sense? Does anyone in
particular want to take on the responsibility of any of these items? I think
we need 1-5 either done or pretty close to done this month. The LSPP work
would dovetail into #6-#8 nicely.
[Date Prev][Date Next] [Thread Prev][Thread Next]