Re: Kernel patches needed
On Thu, 2013-05-09 at 09:26 -0400, Steve Grubb wrote:
Hi,
I was just doing some validation work to make sure the newly converted
ausearch is producing the exact same output as it used to...and found a couple
items that needs patching.
1) AUDIT_TTY events are not recording a subject field.
This is just dumb. Seems to me that we need a new record type. Maybe
something like AUDIT_TASK_INFO? It should dump out the task info like
the pid, uid, gid, auid, ses, comm, subj etc. We really really really
should stop randomly spattering these pieces on info through other
record types. Make those record types small and easy to parse. Make
this record type small and consistent for everything. Why should we
ahve to parse all of this crap out different for a SYSCALL, vs USER, vs
TTY, vs MAGIC_BEANS? Just make all of the task info an aux record we
dump by default.
Just please, can we stop with the random ad hoc adding of fields to
random records?
Pretty pretty please?
No no, really.
Please?
With a cherry on top?
2) AVC records can sometimes have dev="md1". The dev field
is documented as
being the numeric device number. Cases like this should be changed to
"devname" which can be encoded.
Hmmm. Interesting. AVC's have been outputting dev= as an untrusted
string since the beginning. Ok, maybe not the beginning of time, but
since SELinux was introduced on Thu Jul 31 19:54:11 2003. The audit
system wasn't added until Sun Apr 11 23:29:12 2004. So if anything, the
AVC behavior is right and the audit system behavior is wrong. The
'right' thing would be the fix the code that came later and screwed it
up. Thus we should change the audit system so that instead of dev=%02x:
%02x we output major=%02x minor=%02x.
Realistically, that would probably break some audit tools. So I'm not
actually suggesting that. I'm guessing that no tools care if we change
it in the LSM code but this is OLD behavior. I don't like the tone of
assumption that the documentation is correct, when clearly it is audit
which has been wrong since it was first introduced.
I'd suggest opening a BZ so it doesn't get lost.
3) We might need a supplemental record for *setxattr. The flags field
is the
fifth argument and not recorded anywhere.
How have we gotten along without this for so long? Do we really care
about the difference between XATTR_CREATE and XATTR_REPLACE? Those are
the only 2 flags...
If so put some justification in a RH bz...