New development

[Linda Knippers]

Hi Steve,

Thanks for sending this out.  I have some thoughts below.

Steve Grubb wrote:
> 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.

Do you have some thoughts on priority?  Some seem more important
to me than others.
> 
> 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.

It would be good to get some feedback on how important this is.  I don't
have an opinion on this one.

> 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. 

I think some of this has as much to do with correctness as with
performance so maybe we could separate that out.

> 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.

I agree.  I don't know much about the rules are handled but I've seen
the performance impact of having rules so I'd like to know more and see
if we can make some improvements.

> 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.

What about auditing based on domain/type if SELinux is enabled?
If you wanted all the apache  activity, wouldn't you want to audit
anything of that type?

> 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?

I can think of one that we saw on the RHEL3 (LAuS) rules and that is the
ability to have one rule that described a class of system files that
were of interest.  For example, a way to specify that you're interested
in writes to files in /etc that aren't world writable would be handy
because you could audit alot of interesting files without having to
list each one.
> 
> 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.

Are you thinking that there would be an LSPP message type?  Would that
just be for messages that are unique for LSPP?  Do you have an example?
Or would there be two levels of information that one could request so
that getting the additional information required for LSPP would be
optional?

> 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.

I think this one is pretty important.  There is too much duplicate
information in the current records, especially with the watches.

I was also wondering about enhancements to ausearch to provide more
concise audit information, maybe a terse mode that summarized the
information currently provided in the SYSCALL, CWD, PATH, FS_WATCH
and FS_INODE information.  I think that would be helpful even if
the duplicate information is eliminated.
> 
> 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.

Do you think anyone will object to some of the feature enhancements in
the 1-5 range going into the 2.6.9 series?  At some point we'll want to
converge on single series, maybe at the end of the month if that's
about when the LSPP work starts (reading below).
> 
> 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.
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
>