New development

[Steve Grubb]

On Monday 12 September 2005 11:51, Linda Knippers wrote:
> Do you have some thoughts on priority?

I put that at the end. To summarize, I think 1 & 2 should be done first. We 
should look at 3,4,5 to see if they can be put into 2.6.9 series kernel 
without breakage. After that we switch over to rawhide and start LSPP/RBAC 
patching. 6,7,8 fall into that category.

> > 1) Syscall auditing enhancements. Collect all args to execve. This would
> > be implemented as an aux record like the  socket_addr type. 

This is very important and was missed in that last development effort. The 
audit system currently collects the first 4 arguments. The way it collects 
them is in this case is the string's address. This is totally useless. You do 
get to see what was executed because a path record is emitted. However, there 
are a lot of times that you want to know the parameters passed.

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

I elaborated on the one that's really important.

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

Good. This really needs some help.

> > 3) Ability to track child processes. 
<snip>
> What about auditing based on domain/type if SELinux is enabled?

I feel like this is LSPP work. In just a CAPP environment there needs to be a 
mechanism for this.

> If you wanted all the apache activity, wouldn't you want to audit
> anything of that type?

Well, there are domain transitions for cgi. Maybe the cgi calls sendmail, etc.

> > 4) More operators for filters.
<snip>
> 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.

This would be good to add to the list. Anyone else agree?

> > 5) Ability to filter on message type.
<snip>
> Are you thinking that there would be an LSPP message type?

Possibly.

> Would that just be for messages that are unique for LSPP?  Do you have an
> example? 

Yes, the cups printer messages is one place.

> Or would there be two levels of information that one could request so
> that getting the additional information required for LSPP would be
> optional?

This is what I'm leaning towards for almost everything in kernel. I think we 
want to group everything to make this filtering easy to express from 
auditctl.

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

Yes. I want to review all the messages to make sure that we have common 
patterns that make this easy. This will take a little thought to get right. I 
really think it involves restructuring this somewhat.

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

1 & 2 - I don't expect any objections.

> At some point we'll want to converge on single series,

Yes. This is really targeting U3 kernel before we jump into things that aren't 
backward portable. I really don't think the first few will take long. There 
will be some changes that we look at and say...this just doesn't fit. When 
that happens, we jump to rawhide.

-Steve