public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: linux-audit@redhat.com
Subject: Relying on syscall record for information and useless key/value duplication
Date: Wed, 11 Jan 2012 16:10:16 -0500	[thread overview]
Message-ID: <1326316216.3710.13.camel@localhost> (raw)

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.

             reply	other threads:[~2012-01-11 21:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11 21:10 Eric Paris [this message]
2012-01-11 22:36 ` Relying on syscall record for information and useless key/value duplication Linda Knippers
2012-01-12  3:00 ` Steve Grubb
2012-01-12  4:10   ` Linda Knippers
2012-01-12 14:00   ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1326316216.3710.13.camel@localhost \
    --to=eparis@redhat.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox