[redhat-lspp] Re: adding session id information to audit records in RHEL5

[Linda Knippers]

Eric Paris wrote:
> For RHEL 5.2 I plan on adding a new field to a number of audit records.
> The session id.  Whenever the loginuid is set for a task a unique
> session number will be assigned as well.  The sessions number should
> make it easier to coordinate future audit records (like syscalls and
> avcs or whatever) to login records.  Say root logs in twice at the same
> time.  It hard to determine which audit records belong to which root
> login.
> 
> An example can be seen below.  Notice I added a ses= field right after
> the auid= and uid=
> 
> type=SYSCALL msg=audit(1197571662.907:27): arch=c000003e syscall=62 success=yes exit=0 a0=1 a1=f a2=0 a3=0 items=0 ppid=2544 pid=2549 auid=0 uid=0 gid=0 ses=2 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="bash" exe="/bin/bash" subj=root:system_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> 
> type=LOGIN msg=audit(1197571780.103:31): login pid=2821 uid=0 old auid=4294967295 new auid=0 old ses=4294967295 new ses=3
> 
> My real question is not whether this is a good idea but more how are the
> certification tests going to react to having new information appear in
> the records?  I understand that sgrubb's audit log parsing library will
> continue to happily work.  I also think this placement is the best since
> this information is used in aggregating logging information and
> identifying messages having it near the beginning is appropriate.  If
> you disagree with the placement in general you are probably going to
> have to repeat your disagreement on the audit list in a couple hours
> when I push an actual patch upstream.
> 
> But for RHEL5 I could maybe be convinced to put it at the end if it will
> prove to be problematic.  Since upstream and RHEL6 are going to have it
> in the middle am I better off just putting it in the beginning/middle in
> RHEL5 rather than the end?

I think our tests won't care about the placement as long as its not
in the middle of a quoted string, which it isn't in this case.

Thanks for asking.

-- ljk
> 
> -Eric
>