From mboxrd@z Thu Jan 1 00:00:00 1970 From: Burn Alting Subject: Re: New draft standards Date: Mon, 28 Dec 2015 18:24:51 +1100 Message-ID: <1451287491.3232.102.camel@swtf.swtf.dyndns.org> References: <1736195.o09BuzvBta@x2> <7685993.nLr6Gj3DPT@x2> <1451176259.3232.99.camel@swtf.swtf.dyndns.org> <2221771.1qUNZOCjO5@x2> Reply-To: burn@swtf.dyndns.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2221771.1qUNZOCjO5@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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