From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linda Knippers Subject: Re: Relying on syscall record for information and useless key/value duplication Date: Wed, 11 Jan 2012 23:10:33 -0500 Message-ID: <4F0E5D39.1070202@hp.com> References: <1326316216.3710.13.camel@localhost> <201201112200.41660.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201201112200.41660.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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