Relying on syscall record for information and useless key/value duplication

Relying on syscall record for information and useless key/value duplication

[Eric Paris]

So I realized today that we have overlapping information in records and
I don't like it.  A great example would be the MAC_STATUS record and how
you can get duplicate info.  Looking at that following output.

type=MAC_STATUS msg=audit(1326314451.473:1018): enforcing=0 old_enforcing=1 auid=4166 ses=2
type=SYSCALL msg=audit(1326314451.473:1018): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fffc73e1200 a2=1 a3=0 items=0 ppid=3110 pid=21435 auid=4166 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=2 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

What you see is that the MAC_STATUS record tells us more than about the
mac status.  It also includes the auid and ses.  Why only that info?
Why not other info like the SELinux context?  What really bothers me is
that We already get that info (and a lot more info) in the SYSCALL
record.  I believe this is bogus.  What I'd like to do is to create a
new record called the 'TASK_INFO' record that will contain:

ppid pid auid uid gid euid suid fsuid egid sgid fsgid tty ses comm exe
subj

And have this record be 'automagically' emitted any time any record is
emitted.  Thus we don't have information duplication and even if you
have rules to exclude the SYSCALL record you still get all the info you
ever needed for the MAC_STATUS record you wanted.

Does this make sense?  Is there a reason not to do this?  It makes the
code smaller, faster, easier to maintainer, and MUCH easier to prove
correct and complete.  It logically separates the info that is from the
task doing the action from the records which are supposed to report on
individual actions.

Shouldn't MAC_STATUS be about the mac status?  Shouldn't config change
records be about the config that changed?  Shouldn't the xfrm records be
about XFRM?  Obviously attributing these actions to a given task is
important, but it isn't being put where it belongs.

Re: Relying on syscall record for information and useless key/value duplication

[Linda Knippers]

Eric Paris wrote:
> So I realized today that we have overlapping information in records and
> I don't like it.  

You realized this just today?? :-)

> A great example would be the MAC_STATUS record and how
> you can get duplicate info.  Looking at that following output.
> 
> type=MAC_STATUS msg=audit(1326314451.473:1018): enforcing=0 old_enforcing=1 auid=4166 ses=2
> type=SYSCALL msg=audit(1326314451.473:1018): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fffc73e1200 a2=1 a3=0 items=0 ppid=3110 pid=21435 auid=4166 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=2 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> 
> What you see is that the MAC_STATUS record tells us more than about the
> mac status.  It also includes the auid and ses.  Why only that info?
> Why not other info like the SELinux context?  What really bothers me is
> that We already get that info (and a lot more info) in the SYSCALL
> record.  I believe this is bogus.  What I'd like to do is to create a
> new record called the 'TASK_INFO' record that will contain:
> 
> ppid pid auid uid gid euid suid fsuid egid sgid fsgid tty ses comm exe
> subj
> 
> And have this record be 'automagically' emitted any time any record is
> emitted.  

Any time any record is emitted?   This doesn't include auxiliary records,
does it?  So at most, one TASK_INFO record associated with any audit
event, regardless of how many records that event generates?  My concern
is for cases like when we flush the IPsec SPD entries.  That's one SYSCALL
that can turn into 10's (or 100's) of MAC_IPSEC_EVENT records.  Would
I get just one TASK_INFO or one per MAC_IPSEC_EVENT record?  We only need
one since all of these records have the same event number anyway so they'd
be identical.

> Thus we don't have information duplication and even if you
> have rules to exclude the SYSCALL record you still get all the info you
> ever needed for the MAC_STATUS record you wanted.
> 
> Does this make sense?  

I'm all for cleaning things up but I have a couple of questions.

Are you also planning to change the basic AVC message so it would require
a TASK_INFO message?

What about audit records that aren't associated with syscalls, such
as all the messages that originate in user space?  Just looking at one
of my systems, I see things like CRYPTO_KEY_USER, DAEMON_START, all
the AUTH-related records, etc.  They have some of the same stuff.

> Is there a reason not to do this?  

Breaking legacy programs?

Will this break programs that are only looking at a specific record type?
For example, the MAC_IPSEC_EVENT record also has an auid, ses, and subj.
The information in that record could be all anyone ever wanted for monitoring
the SPD activity, even though there is also a SYSCALL record with even more
information.  If they never looked at the SYSCALL record before, now they'll
have to look at the TASK_INFO record?

Most importantly (to me), will it break the audit-test suite?  We try to be fuzzy
in the way we look for information but we do have tests that look for
a SYSCALL record looking for subj, auid, success, name and obj fields, for
example.  Our test suite is smart enough to collect all the auxillary records
(CWD, PATH, etc) so if the TASK_INFO is associated with the syscall and the
field names are the same, things might just work.  I'd want to be sure of that.

> It makes the
> code smaller, faster, easier to maintainer, and MUCH easier to prove
> correct and complete.  It logically separates the info that is from the
> task doing the action from the records which are supposed to report on
> individual actions.
> 
> Shouldn't MAC_STATUS be about the mac status?  Shouldn't config change
> records be about the config that changed?  Shouldn't the xfrm records be
> about XFRM?  Obviously attributing these actions to a given task is
> important, but it isn't being put where it belongs.

Would have loved to see this about 6 years ago. :-)

-- ljk
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Relying on syscall record for information and useless key/value duplication

[Steve Grubb]

On Wednesday, January 11, 2012 04:10:16 PM Eric Paris wrote:
> So I realized today that we have overlapping information in records and
> I don't like it.

I have a real strong feeling that you did it. :-)  I'm not searching the 
archives for proof...but I remember it went something like this...we needed a 
MAC event showing it changed. We needed some basic info. Then later we needed 
some more info and then someone just changed it to dump the syscall record. In 
many cases, this is bloat.

What is required is much less fields and I would like to keep the overall event 
size as small as possible. Do I need a MAC_STATUS event?  Yes. Do I need to know 
the syscall? no.


> A great example would be the MAC_STATUS record and how
> you can get duplicate info.  Looking at that following output.
> 
> type=MAC_STATUS msg=audit(1326314451.473:1018): enforcing=0 old_enforcing=1
> auid=4166 ses=2 type=SYSCALL msg=audit(1326314451.473:1018): arch=c000003e
> syscall=1 success=yes exit=1 a0=3 a1=7fffc73e1200 a2=1 a3=0 items=0
> ppid=3110 pid=21435 auid=4166 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts3 ses=2 comm="setenforce" exe="/usr/sbin/setenforce"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> 
> What you see is that the MAC_STATUS record tells us more than about the
> mac status.  It also includes the auid and ses.  Why only that info?

What is required is this:
Date and time of the event, 
type of event, 
subject identity (if applicable), 
the outcome (success or failure) of the event
and additional data depending on the event, like what configuration item changed 
(with old and new values), what was accessed, etc.

We have additional requirements of being able to trace each event back to an 
actual login hence the session data. Then you also have to record enough 
information about the subject that its useful. This includes at a minimum auid, 
uid, pid, and selinux context.


> Why not other info like the SELinux context? 

I think when we asked for that, you added a line of code to grab the whole 
syscall since that was the simplest thing to do. :-)


> What really bothers me is that We already get that info (and a lot more info)
> in the SYSCALL record.  I believe this is bogus.  What I'd like to do is to
> create a new record called the 'TASK_INFO' record that will contain:
> 
> ppid pid auid uid gid euid suid fsuid egid sgid fsgid tty ses comm exe
> subj

Probably too much info and too late. I have a feeling that a change like this 
now would cause more problems than its worth.

I want to aim the audit system such that it can meet the new basic robustness 
protection profile. Meeting it would also allow meeting any other PP that I know 
of. It will require reviewing all audit records to make sure they conform to the 
new requirements.

http://www.niap-ccevs.org/pp/PP_GPOSPP_V1.0/

I'd really like to avoid any massive changes in record format until that work 
begins in earnest later this year. I want to create some regression testing 
tools in the mean time so that as we move forward, we can stay backwards 
compatible. Imagine an aggregating server with several different Linux platforms 
being aggregated and still being able to use the current tools. It has to be 
done.

Please, let's not go down this rat hole just yet. I'd rather catch up on the 
known bugs in the audit system like 

https://bugzilla.redhat.com/show_bug.cgi?id=742562

then around summer/late spring start working towards GPOSPP's requirements and 
possibly reformat some events as part of that work.

-Steve

Re: Relying on syscall record for information and useless key/value duplication

[Linda Knippers]

Steve Grubb wrote:
> On Wednesday, January 11, 2012 04:10:16 PM Eric Paris wrote:
>> So I realized today that we have overlapping information in records and
>> I don't like it.
> 
> I have a real strong feeling that you did it. :-)  I'm not searching the 
> archives for proof...but I remember it went something like this...we needed a 
> MAC event showing it changed. We needed some basic info. Then later we needed 
> some more info and then someone just changed it to dump the syscall record. In 
> many cases, this is bloat.
> 
> What is required is much less fields and I would like to keep the overall event 
> size as small as possible. Do I need a MAC_STATUS event?  Yes. Do I need to know 
> the syscall? no.
> 
> 
>> A great example would be the MAC_STATUS record and how
>> you can get duplicate info.  Looking at that following output.
>>
>> type=MAC_STATUS msg=audit(1326314451.473:1018): enforcing=0 old_enforcing=1
>> auid=4166 ses=2 type=SYSCALL msg=audit(1326314451.473:1018): arch=c000003e
>> syscall=1 success=yes exit=1 a0=3 a1=7fffc73e1200 a2=1 a3=0 items=0
>> ppid=3110 pid=21435 auid=4166 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
>> sgid=0 fsgid=0 tty=pts3 ses=2 comm="setenforce" exe="/usr/sbin/setenforce"
>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
>>
>> What you see is that the MAC_STATUS record tells us more than about the
>> mac status.  It also includes the auid and ses.  Why only that info?
> 
> What is required is this:
> Date and time of the event, 
> type of event, 
> subject identity (if applicable), 
> the outcome (success or failure) of the event
> and additional data depending on the event, like what configuration item changed 
> (with old and new values), what was accessed, etc.
> 
> We have additional requirements of being able to trace each event back to an 
> actual login hence the session data. Then you also have to record enough 
> information about the subject that its useful. This includes at a minimum auid, 
> uid, pid, and selinux context.
> 
> 
>> Why not other info like the SELinux context? 
> 
> I think when we asked for that, you added a line of code to grab the whole 
> syscall since that was the simplest thing to do. :-)
> 
> 
>> What really bothers me is that We already get that info (and a lot more info)
>> in the SYSCALL record.  I believe this is bogus.  What I'd like to do is to
>> create a new record called the 'TASK_INFO' record that will contain:
>>
>> ppid pid auid uid gid euid suid fsuid egid sgid fsgid tty ses comm exe
>> subj
> 
> Probably too much info and too late. I have a feeling that a change like this 
> now would cause more problems than its worth.
> 
> I want to aim the audit system such that it can meet the new basic robustness 
> protection profile. Meeting it would also allow meeting any other PP that I know 
> of. It will require reviewing all audit records to make sure they conform to the 
> new requirements.
> 
> http://www.niap-ccevs.org/pp/PP_GPOSPP_V1.0/
> 
> I'd really like to avoid any massive changes in record format until that work 
> begins in earnest later this year. I want to create some regression testing 
> tools in the mean time so that as we move forward, we can stay backwards 
> compatible. 

Feel free to submit patches for any missing tests to audit-test-developer@lists.sourceforge.net.

> Imagine an aggregating server with several different Linux platforms 
> being aggregated and still being able to use the current tools. It has to be 
> done.
> 
> Please, let's not go down this rat hole just yet. I'd rather catch up on the 
> known bugs in the audit system like 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=742562
> 
> then around summer/late spring start working towards GPOSPP's requirements and 
> possibly reformat some events as part of that work.
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Relying on syscall record for information and useless key/value duplication

[Steve Grubb]

On Wednesday, January 11, 2012 10:00:41 PM Steve Grubb wrote:
> Please, let's not go down this rat hole just yet. I'd rather catch up on
> the  known bugs in the audit system like
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=742562

We also have this bug:

https://www.redhat.com/archives/linux-audit/2011-December/msg00030.html

which really needs looking into more than reformatting the events.

-Steve