New draft standards

[Burn Alting]

On Sun, 2015-12-27 at 10:06 -0500, Steve Grubb wrote:
> 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.
> 

I wasn't too concerned about the interleaved events but the incorrect
use of the audit message as per

type=USER_CHAUTHTOK msg=audit(12/28/2015 18:00:30.858:17862432) :
pid=13418 uid=root auid=burn ses=1
subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 msg='op=change
password id=burn exe=/usr/bin/passwd hostname=? addr=? terminal=pts/0
res=success' 

where auparse with discard the string 'password' changing

	op=change password id=burn exe=/usr/bin/passwd
to
	op=change id=burn exe=/usr/bin/passwd

> 
> > 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