[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]