Re: [PATCH v2 0/2] RFC, aiding pid/network correlation

[Alex Elsayed <eternaleye@gmail.com>]

Alex Elsayed wrote:

> Peter Moody wrote:
> 
>> 
>> On Sat, Aug 02 2014 at 19:28, Alex Elsayed wrote:
>> 
>>> Oh, I see now. Okay, that's actually considerably simpler - I just had
>>> somehow gotten it fixated into my mind that the info would be used to
>>> decide on allow/deny actions.
>>>
>>> The trick to do what you want is the 'audit' support in both -
>>> here I'll use CaitSith as an example since the syntax is nicer.
>> 
>> Do these audit logs end up with the audit subsystem? My experience with
>> the audit subsystem is that performance takes a big hit when you start
>> sending thousands (or even hundreds) of audit messages per second.
> 
> No, they go straight to /proc/caitsith/audit and wind up looking like
> this:
> 
> #2012/04/08 05:03:03# global-pid=3720 result=allowed priority=100 / read
> path="/tmp/file1" task.pid=3720 task.ppid=3653 task.uid=0 task.gid=0
> task.euid=0 task.egid=0 task.suid=0 task.sgid=0 task.fsuid=0 task.fsgid=0
> task.type!=execute_handler task.exe="/bin/cat"
> task.domain="/usr/sbin/sshd" path.uid=0 path.gid=0 path.ino=2113451
> path.major=8 path.minor=1 path.perm=0644 path.type=file
> path.fsmagic=0xEF53 path.parent.uid=0 path.parent.gid=0
> path.parent.ino=2097153 path.parent.major=8 path.parent.minor=1
> path.parent.perm=01777 path.parent.type=directory
> path.parent.fsmagic=0xEF53

Actually, now that I look at that, you'd need to audit 'domain transition' 
events too - since that contains all the relevant PIDs, then the most recent 
domain transition with all of the right PIDs is sufficient to rebuild the 
tree back to init (recursively)