12:55 p.m.
Hello,
I am in the process of reviewing the requirements for the next round of
development for the audit system. I've worked out a rough schedule for the
user space side of things. I will produce more documentation over the next
couple of days describing what is needed and what would be nice to add. I
would like for this to be an open discussion among all parties as this
affects the whole linux community.
The rough schedule for the next series goes something like this:
1.1 -> 1.2 event dispatcher, plugin framework, and some basic plugins
1.2 -> 1.3 label support + more plugins
1.3 -> 1.4 add new config options, summary reports, binary format
1.4 -> 1.5 audit explorer & gui config
There are several reasons for doing plugins first. Partly due to limited time
of people working on it and also to give file system auditing a chance to get
upstream. This way we are working in parallel.
If you have ideas about nice things to add, lets start the discussion. We
don't need to talk about LSPP as that will be by-the-book. (I want that
discussion to be its own thread, but not yet. This is just pie in the sky
planning.) I'm looking for usability and neat to have items.
Another thing I'd like to point out is that the plugin architecture will let
us eventually layer an IDS on top of the audit system. This is a long range
goal that will take some time to get to.
-Steve
8:14 a.m.
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.
-Steve
10:51 a.m.
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(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
11:18 a.m.
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
12:12 p.m.
>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.
I don't think its strictly related to LSPP since LSPP doesn't need
type enforcement, although it will be there. To me its more SELinux
integration, which is also necessary for LSPP but this part could be
done separately. If a CAPP customer also wanted to audit the
apache-related processes, they're probably also running with SELinux
enabled so that's what I was thinking of. I agree though that being
able to audit any random process and its children can be useful, and
maybe the domain transitions make this too hard.
>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.
But would that really be an LSPP message type? What if MCS users want
to audit the cups activity? Maybe I'm taking the LSPP type too
literally? We don't have a CAPP message type today so that's why I'm
confused about the purpose of an LSPP type.
-- ljk
12:26 p.m.
On Monday 12 September 2005 13:12, Linda Knippers wrote:
>>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.
I don't think its strictly related to LSPP since LSPP doesn't need
type enforcement, although it will be there.
I lump all the LSPP/MCS work and tightening the audit system with SE Linux as
"LSPP" work. I don't want to mess with type enforcement until the message
numbering is settled. That decision has the new operators as a pre-requisite.
If new operators can't be done, then the way we filter these will have to be
via a different mechanism.
If a CAPP customer also wanted to audit the apache-related
processes,
they're probably also running with SELinux enabled so that's what I was
thinking of.
Maybe not. Suppose they are doing large database system. They may decide to
turn SE Linux off. We really cannot depend on that since they are free to
boot with it on or off. This has to stand on its own.
>> Would that just be for messages that are unique for LSPP?
Do you have
>> an example?
>
> Yes, the cups printer messages is one place.
But would that really be an LSPP message type?
Yes. Its not needed at all for CAPP.
What if MCS users want to audit the cups activity?
MCS is virtually the same configuration as LSPP - just a simplified policy.
But from our perspective in the audit system, it is LSPP. We need to have the
labels in the audit messages.
Maybe I'm taking the LSPP type too literally?
We don't have a CAPP message type today so that's why I'm
confused about the purpose of an LSPP type.
Right now, I consider everything CAPP. The SE Linux messages I'm still mulling
over their classification. They could arguably go either way. All new SE
Linux messages for the support of MCS and LSPP would fall into the LSPP
category.
-Steve
1:17 p.m.
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
1:39 p.m.
On Monday 12 September 2005 14:17, Amy Griffis wrote:
> 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?
General usage. I've already received emails about this omission from people
that will be using the audit system.
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.
OK, I'd like to have a separate mail thread for user space enhancements. I
have a list of those as well and limited this thread to kernel changes. I
like the idea though.
One other nice-to-have is the ability to specify some symbolic
constants in rules, e.g. ioctl control constants.
Right. again user space. I am wanting to do that as a separate thread in about
a week. I want to get LSPP stuff out later this week.
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 this is a dwmw2 judgment, but my guess is no. That code is likely to
be rawhide unless RHEL4 picks up inotify. Until then, we have something that
works. Don't underestimate its importance based on what I just said...FC4
users do not have a working audit system. Rawhide doesn't either.
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?
The auditfs code is on the critical path. That needs to be done asap. If
anyone has time or ideas about performance, they should let the mail list
know. Maybe there's times when you are waiting for feedback that you might
want to look at it a little.
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'd rather not. Dustin's patch introduces a new message number. I need to see
where we are on filtering to decide what the numbers are going to look like.
That in turn depends on filtering operators. There are some pre-requisites
that need to be satisfied before inserting his patch. I also see the work on
1-5 as a way to make progress while allowing time for auditfs to get
upstream.
I also did not mention bug fixing in the mail from this morning. We are
starting to get several bugs that are found and unresolved.
-Steve
2:38 p.m.
On Mon, 2005-09-12 at 14:17 -0400, Amy Griffis wrote:
I know Dustin has been working on some LSPP development, and he
expressed interest in incorporating his patch somewhere when it's
ready.
Amy is correct--I'd like to continue working on the enhancements of
audit required for LSPP compliance. Today is my first day back from a
week's vacation, and I intend on resubmitting an updated lspp_audit
patch incorporating Amy/Steve's latest suggestions within the next day
or two. Perhaps after this patch is integrated, the binary record to-do
sounds interesting to me...
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.
I've been diffing against the latest -mm tree when I submit these
lspp_audit patches, as per David Woodhouse's request. Let's agree on a
different tree if that's where we're going.
:-Dustin
3 p.m.
On Monday 12 September 2005 14:38, Dustin Kirkland wrote:
<snip>
. Perhaps after this patch is integrated, the binary record to-do
sounds interesting to me...
:-Dustin
So we have talked about this in the past and it was indeed slated for EAL4, but was
dropped in
favor of plaintext. This is a good place to start,
http://www-aix.informatik.uni-tuebingen.de/doc_link/en_US/a_doc_lib/aixpr...
I'm partial to using XDR as it's already in the kernel (net/sunrpc/xdr.c) and
addresses, by design,
some of the nasty issues that surface when using a binary record format (ie: 32-bit vs.
64-bit).
We're also going to want to converge on a set of standard tokens and some have
suggested we
go with the (Basic Security Module) BSM set of audit tokens. Here's a good paper here
on this
subject,
http://72.14.207.104/search?q=cache:wXnO2bVvxiMJ:dependability.cs.virgini...
(Looks like the original PDF was removed)
And it's worth checking out the TrustedBSD implementation...
http://fxr.watson.org/fxr/source/bsm/?v=TRUSTEDBSD-AUDIT3
-tim
7040
days inactive
7058
days old
linux-audit@lists.linux-audit.osci.io
9 comments
5 participants
participants (5)
-
Amy Griffis -
Dustin Kirkland -
Linda Knippers -
Steve Grubb -
Timothy R. Chavez