xt_AUDIT additions

xt_AUDIT additions

[Mr Dash Four]

I would like to add 3 more pieces of information to the audit target to 
be included in the audit logs:

1. pid/uid -> auid + program path (auid and program path is retrievable 
once the pid is known) - outgoing packets only, obviously;
2. tcpflags, where applicable; and
3. tos information, again, where applicable;

The last two are more-or-less directly retrievable as they are included 
in the tcphdr and iphdr structs respectively, but I am struggling to 
find a reliable source for the first one - uid/pid information.

I know this information *should* be available as outgoing packets are 
bound to sockets and those are created by a process, but I am struggling 
to find a reliable source which I could use. I looked at both ss and 
netstat sources, but the approach there is very different as they both 
use/scan "/proc" to retrieve this information and I am not sure this is 
the best way to approach things for the kernel code of the audit target.

Is there any other quicker/reliable way?

Having pid/uid, the program path and auid in particular (i.e. the audit 
id - the "master" session of the root process owning the process to 
which the socket/outgoing packet is bound) included in the audit logs 
would be invaluable piece of information as the source of the packets 
could be easily traced to the process (or processes) which created it 
and the user id used. It would also help with cross-referencing with 
other uid/pid/auid information from the audit logs to discover patterns 
of interest to the auditors/sys admins.

Re: xt_AUDIT additions

[Jan Engelhardt]

On Friday 2011-07-01 00:42, Mr Dash Four wrote:

>I would like to add 3 more pieces of information to the audit target to 
>be included in the audit logs:
>
>1. pid/uid -> auid + program path (auid and program path is retrievable 
>once the pid is known) - outgoing packets only, obviously;
>
>I know this information *should* be available as outgoing packets are 
>bound to sockets and those are created by a process, but I am 
>struggling to find a reliable source which I could use. I looked at 
>both ss and netstat sources, but the approach there is very different 
>as they both use/scan "/proc" to retrieve this information and I am not 
>sure this is the best way to approach things for the kernel code of the 
>audit target.

xt_owner did the same - it scanned the process table. According to 
Christoph Hellwig, this was declared as some gross abuse, and, IIRC, the 
reason was something like the tasklist lock was held "quite long" (which 
makes sense). However, xt_owner did not held the tasklist [write] lock, 
just entered a RCU read section. hch: Was this RCU section also too 
long?

xt_owner had the bonus that it only had to check whether the socket was 
owned by a particular user/group/pid/sid, which means it can stop 
looping the tasklist as soon as it found a match.

But with xt_AUDIT, you would have to traverse the entire list, because 
you would want to find all PIDs - since a socket may be shared between 
multiple threads/processes - which in itself may generate a huge list 
(=another problem) in the audit records.

Also, the PID owner may not be the socket owner for the same reason.

Re: xt_AUDIT additions

[Mr Dash Four]

> xt_owner did the same - it scanned the process table. According to 
> Christoph Hellwig, this was declared as some gross abuse, and, IIRC, the 
> reason was something like the tasklist lock was held "quite long" (which 
> makes sense).
Yep, it is the reason I was very reluctant to use this approach and seek 
to find another, more "efficient" way.

> However, xt_owner did not held the tasklist [write] lock, 
> just entered a RCU read section. hch: Was this RCU section also too 
> long?
>
> xt_owner had the bonus that it only had to check whether the socket was 
> owned by a particular user/group/pid/sid, which means it can stop 
> looping the tasklist as soon as it found a match.
>   
I'll have a look at the xt_owner code later to see if there is something 
I could use/learn.

> But with xt_AUDIT, you would have to traverse the entire list, because 
> you would want to find all PIDs - since a socket may be shared between 
> multiple threads/processes - which in itself may generate a huge list 
> (=another problem) in the audit records.
>   
Isn't there a more efficient solution to this? The thought of scanning 
the task list to find ids for a single packet makes my head hurt!

> Also, the PID owner may not be the socket owner for the same reason.
>   
That's where auid comes in - it determines, unequivocally, the "root" 
process owner.

For example: if I log in as root and start a process, which then uses 
another id (say process squid using user id _squid), which spawns 
further processes under the same id, the "normal" uid (i.e. the 
information of the socket "owner") is probably going to show me uid = 
_squid, but the auid will show "root" as this is the "root" session 
which started all sub-processes and I suspect was one of the reasons 
auid was introduced in the first place - to remove this ambiguity.

Re: xt_AUDIT additions

[Mr Dash Four]

>> However, xt_owner did not held the tasklist [write] lock, just 
>> entered a RCU read section. hch: Was this RCU section also too long?
>>
>> xt_owner had the bonus that it only had to check whether the socket 
>> was owned by a particular user/group/pid/sid, which means it can stop 
>> looping the tasklist as soon as it found a match.
>>   
> I'll have a look at the xt_owner code later to see if there is 
> something I could use/learn.
Interesting, thanks for all the pointers!

xt_owner.c does have some answers. 
skb->sk->sk_socket->file->f_cred->fsuid and 
skb->sk->sk_socket->file->f_cred->fsgid seems to point to the socket 
user id/group id owner. That, to my understanding, may not always be the 
uid/gid responsible for sending a particular packet via this particular 
socket, or have I got this wrong?

Moving on to the process id, I take it skb->sk->pid (or is it 
skb->sk->sk_socket->sk->pid?) holds the pid list of the process(es) 
owning the socket, right? Should I assume that the process responsible 
for sending a particular packet could be found by traversing that list 
or do I have to look elsewhere?

Also, am I right in assuming that only one process is responsible for 
sending a particular packet? If that is the case, then there must only 
be a single, unique triple of uid/pid/gid for each packet. If that is 
so, how do I know which uid/pid/gid is responsible for that?