LSPP audit enablement: example audit records with subj/obj labels

[Dustin Kirkland]

I expect that most people have only looked at the code of the
subject/object labeling patch, and have not actually patched a kernel,
compiled, and tested it.

Thus, I'm pasting below a few snippets of the audit logs so that you can
get an idea of what these labels look like, and how they're falling into
place.

At this point, the subj/obj label is simply appended onto the end of the
existing audit record for the associated subject or object.  Steve has
mentioned that this will get more complicated when a given subject acts
on multiple objects (though I haven't found a good way to test this
behavior yet).

Alternatively, the subj/obj label could exist as an auxiliary record and
refer back to the owning record.  This could work as well, but this is
not how my patch is currently written.  It's a little more complicated
than what I have in place now, though probably doable without too much
trouble.  If there are strong feelings one way or another, let's please
discuss them now.

Examples follow.

--

This is the /var/log/audit/audit.log output of a watch on chmod
(auditctl -a exit,always -S chmod).  Note the specified subject context
attached to the syscall record (subj).  Also note the specified object
context attached to the path record (obj).

type=SYSCALL msg=audit(1129732019.179:29): arch=40000003 syscall=15
success=yes exit=0 a0=80528a8 a1=1ed a2=805153c a3=8053a68 items=1
pid=3110 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="chmod" exe="/bin/chmod" subj=root:system_r:unconfined_t
type=CWD msg=audit(1129732019.179:29):  cwd="/tmp"
type=PATH msg=audit(1129732019.179:29): item=0 name="dustin" flags=1
inode=1638928 dev=fd:00 mode=0100777 ouid=500 ogid=500 rdev=00:00
obj=root:object_r:tmp_t


And this is the /var/log/audit/audit.log output of a watch on ipc calls
(auditctl -a exit,always -S ipc).  I created a little test program that
creates, sets, and removes a semaphore (which is where there are several
records here).  Note the subj field in the syscall record, and the obj
field in the IPC record.

type=SYSCALL msg=audit(1129732008.219:26): arch=40000003 syscall=117
success=yes exit=0 a0=3 a1=0 a2=0 a3=101 items=0 pid=3107
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="a.out" exe="/tmp/a.out" subj=root:system_r:unconfined_t
type=IPC msg=audit(1129732008.219:26):  qbytes=0 iuid=2332033043
igid=4294966419 mode=ffff obj=system_u:system_r:unconfined_t
type=SYSCALL msg=audit(1129732008.219:27): arch=40000003 syscall=117
success=yes exit=98306 a0=2 a1=0 a2=1 a3=1ff items=0 pid=3107
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="a.out" exe="/tmp/a.out" subj=root:system_r:unconfined_t
type=SYSCALL msg=audit(1129732008.219:28): arch=40000003 syscall=117
success=yes exit=0 a0=3 a1=18002 a2=0 a3=100 items=0 pid=3107
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="a.out" exe="/tmp/a.out" subj=root:system_r:unconfined_t


:-Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20051019/ae59e088/attachment.sig>