New development

[Amy Griffis]

Hi Steve,

Thanks for drafting an audit development plan.  This is very helpful.

On Mon, Sep 12, 2005 at 12:18:09PM -0400, Steve Grubb wrote:
> > > 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.

Could you clarify whether this is important for a CAPP certification,
or for general audit usage?  I'm trying to understand the priority
here as well.

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

I think this would be good.  Decreasing the size of the rules list
should improve performance.  I haven't thought about how difficult
it would be to add this to the current filter implementation.

Another idea is aliases for groups of syscalls.  You can currently
specify several syscalls in a single filter rule, which shortens your
kernel rules list.  An alias would make the rule more concise, and
could be implemented in auditctl without any kernel changes.

For example, this would result in 3 rules:

  auditctl -a entry,always -S chown
  auditctl -a entry,always -S lchown
  auditctl -a entry,always -S fchown

This would give you one rule:

  auditctl -a entry,always -S chown -S lchown -S fchown

This just makes it more convenient:

  auditctl -a entry,always -S chown-ops

One other nice-to-have is the ability to specify some symbolic
constants in rules, e.g. ioctl control constants.

> > > 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 personally have only noticed duplicate filesystem information.  
Has anyone noticed anything else?

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

<snip>

> > > I think we need 1-5 either done or pretty close to done this
> > > month.

I think that having 1-5 done this month is too optimistic.  Because I
don't yet understand the requirement behind #1, I would say #2
performance would seem the most important for the 2.6.9 series and
that we should focus on that this month.  If we finish ahead of
schedule, we could pick up another item.

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

I'm also trying to visualize where the filesystem audit work fits into
this schedule.  If it's based off of Inotify, or if we end up needing
a solution based on code that hasn't been written yet, would that
really go into the 2.6.9 series?

I think Tim and I are both pretty interested in working on that.  But
if it's not targeted for 2.6.9, do we need to change gears
temporarily?

I know Dustin has been working on some LSPP development, and he
expressed interest in incorporating his patch somewhere when it's
ready.  If we haven't finished 1-5 by the time Dustin's patch is
ready, do you plan to have development going on in multiple kernels at
once?  I ask this because what you said about jumping over would imply
that you are not.

Thanks,
Amy