Re: New development
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