Re: New draft standards

On Sunday, December 27, 2015 11:30:59 AM Burn Alting wrote: > I'll start with the statement I am happy to enhance the audit capability > of Linux in any way (read that as a direct offer to help). Thanks! > > I'm somewhat interested in this. I'm just not sure where the best place to > > do all this is. Should it be in ausearch? Should it be in auditd? Should > > it be in the remote logging plugin? Should audit utilities be modified to > > accept this new form of input? > > I've concentrated on ausearch as this is the only tool that > comprehensively parses all existing audit records, both well formed and > incorrectly formed. As you know auparse() has difficulties with > mal-formed events. Its main problem is dealing with interlaced records. The kernel does not serialize the audit stream. Whatever thread/process is executing at the moment can trigger a multi-part or single line event. For example: type=SYSCALL msg=audit(1396522853.933:313): arch=c000003e syscall=313 success=yes exit=0 a0=0 a1=41a396 a2=0 a3=0 items=1348 ppid=1263 pid=1264 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="modprobe" exe="/usr/bin/kmod" subj=system_u:system_r:insmod_t:s0 key="module-load" type=LOGIN msg=audit(1396522854.227:460): pid=1523 uid=0 old auid=4294967295 new auid=4325 old ses=4294967295 new ses=1 res=1 type=PATH msg=audit(1396522853.933:313): item=0 name=(null) inode=165 dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=PARENT type=PATH msg=audit(1396522853.933:313): item=1 name=(null) inode=11206 dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=CREATE type=LOGIN msg=audit(1396522854.315:461): pid=1518 uid=0 old auid=4294967295 new auid=4325 old ses=4294967295 new ses=1 res=1 type=PATH msg=audit(1396522853.933:313): item=2 name=(null) inode=11206 dev=00:06 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:debugfs_t:s0 nametype=PARENT That should be 3 events.

> Ausearch also has the benefit of not effecting real time performance - I'd not > like auditd have to wait on an external DNS service to timeout when > attempting to resolve an 'addr' field. Yeah, I'm thinking about just breaking down the SOCKADDR record into src/dst ip and src/dst port and then leaving it as that for now. > Whatever is done, the code needs to be modular so that any utility, be > it ausearch, auditd or an audispd plugin, or an independent auparse() > based utility can make use of it. > > Perhaps to address the higher level audit needs, we can provide an > additional output format to my proposed changes for 'interpretive > formatting' to be that of 'descriptive statements'. This would be > similar to Windows auditing when it allows one to include 'Display > Information' field which provides a 'human readable' description of the > event data. I'm not familiar with Windows auditing, but yeah. > Perhaps the thrust should be > a. address performance I might have this solved. I'll send a separate email. > b. ensure auparse() can better deal with mal-formed events This would be a big contribution to the project. > c. provide interpretative formatting Yes. I think this a good order that has the right things in the right priority. There is one other issue that I need to tackle at some point. The auparse library does a lot of string manipulation. As such it winds up doing a lot of strtok/malloc/free. I'd like to see this run faster somehow. Perhaps moving to ustr could help. Or maybe having a list of pointers/lengths to avoid malloc/free. But auparse needs a performance boost, too. -Steve