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