Re: New draft standards

[Steve Grubb <sgrubb@redhat.com>]

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