How to audit socket close system call?

How to audit socket close system call?

[Jie Cui]

[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]

Hi all~
How to audit socket close system call?
I can audit the socket connection by 'connect' system call.
I can also audit the socket termination by 'shutdown' system call.
But I can't figure out how to audit when the socket is closed.
Does the 'close' system call works? However all the file close events will
also be auditing. That's not what I want.

[-- Attachment #1.2: Type: text/html, Size: 696 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: How to audit socket close system call?

[Steve Grubb]

On Friday, December 19, 2014 02:06:52 PM Jie Cui wrote:
> How to audit socket close system call?

There's not a good answer on that one.

> I can audit the socket connection by 'connect' system call.
> I can also audit the socket termination by 'shutdown' system call.
> But I can't figure out how to audit when the socket is closed.

In the past, the kernel developers said that is an exercise left to post 
processing in user space. Meaning that we'd have to collect everything and 
then sort it out after the fact. You have the FD returned from socket(2). So, 
you can audit closes and then match the FD.

Unfortunately, you'll get all closes for all programs unless you had some way 
to restrict it to the process in question. There is a patch under development 
for audit by process name. That would at least have allowed restricting closes 
to a particular program which would be more manageable.


> Does the 'close' system call works?

Yes.

> However all the file close events will also be auditing. That's not what I
> want.

I can understand. But, there is nothing in the present kernel except pid, 
auid, and subj_type to restrict the auditing in a logical way. If you can 
think of another way, please propose it. But all the kernel has to work with 
is an fd number and what's in the process struct. Audit by process name holds 
the most hope for limiting what gets collected.

-Steve

Re: How to audit socket close system call?

[Hassan Sultan]

Are you interested in the syscalls on sockets specifically, or are you  
interested in the network connections underlying these calls instead ?

You could use netfilter/conntrack instead of auditd if your interest  
really is the network connections rather than sockets. You'll get notified  
of the various TCP states, so even if a socket is closed rather than  
shutdown (say when a process dies), you should be able to know about it  
that way.

Thanks,

Hassan

On Fri, 19 Dec 2014 06:37:15 -0800, Steve Grubb <sgrubb@redhat.com> wrote:

> On Friday, December 19, 2014 02:06:52 PM Jie Cui wrote:
>> How to audit socket close system call?
>
> There's not a good answer on that one.
>
>> I can audit the socket connection by 'connect' system call.
>> I can also audit the socket termination by 'shutdown' system call.
>> But I can't figure out how to audit when the socket is closed.
>
> In the past, the kernel developers said that is an exercise left to post
> processing in user space. Meaning that we'd have to collect everything  
> and
> then sort it out after the fact. You have the FD returned from  
> socket(2). So,
> you can audit closes and then match the FD.
>
> Unfortunately, you'll get all closes for all programs unless you had  
> some way
> to restrict it to the process in question. There is a patch under  
> development
> for audit by process name. That would at least have allowed restricting  
> closes
> to a particular program which would be more manageable.
>
>
>> Does the 'close' system call works?
>
> Yes.
>
>> However all the file close events will also be auditing. That's not  
>> what I
>> want.
>
> I can understand. But, there is nothing in the present kernel except pid,
> auid, and subj_type to restrict the auditing in a logical way. If you can
> think of another way, please propose it. But all the kernel has to work  
> with
> is an fd number and what's in the process struct. Audit by process name  
> holds
> the most hope for limiting what gets collected.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: How to audit socket close system call?

[Steve Grubb]

On Saturday, December 20, 2014 11:39:47 AM Hassan Sultan wrote:
> Are you interested in the syscalls on sockets specifically, or are you
> interested in the network connections underlying these calls instead ?
> 
> You could use netfilter/conntrack instead of auditd if your interest
> really is the network connections rather than sockets.

There is also an AUDIT target for netfilter rules so that events you are 
interested in are recorded in the audit log.

-Steve

> You'll get notified of the various TCP states, so even if a socket is closed
> rather than shutdown (say when a process dies), you should be able to know
> about it that way.
> 
> Thanks,
> 
> Hassan
> 
> On Fri, 19 Dec 2014 06:37:15 -0800, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Friday, December 19, 2014 02:06:52 PM Jie Cui wrote:
> >> How to audit socket close system call?
> > 
> > There's not a good answer on that one.
> > 
> >> I can audit the socket connection by 'connect' system call.
> >> I can also audit the socket termination by 'shutdown' system call.
> >> But I can't figure out how to audit when the socket is closed.
> > 
> > In the past, the kernel developers said that is an exercise left to post
> > processing in user space. Meaning that we'd have to collect everything
> > and
> > then sort it out after the fact. You have the FD returned from
> > socket(2). So,
> > you can audit closes and then match the FD.
> > 
> > Unfortunately, you'll get all closes for all programs unless you had
> > some way
> > to restrict it to the process in question. There is a patch under
> > development
> > for audit by process name. That would at least have allowed restricting
> > closes
> > to a particular program which would be more manageable.
> > 
> >> Does the 'close' system call works?
> > 
> > Yes.
> > 
> >> However all the file close events will also be auditing. That's not
> >> what I
> >> want.
> > 
> > I can understand. But, there is nothing in the present kernel except pid,
> > auid, and subj_type to restrict the auditing in a logical way. If you can
> > think of another way, please propose it. But all the kernel has to work
> > with
> > is an fd number and what's in the process struct. Audit by process name
> > holds
> > the most hope for limiting what gets collected.
> > 
> > -Steve
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit

Re: How to audit socket close system call?

[Alexander Viro]

On Fri, Dec 19, 2014 at 02:06:52PM +0800, Jie Cui wrote:
> Hi all~
> How to audit socket close system call?
> I can audit the socket connection by 'connect' system call.
> I can also audit the socket termination by 'shutdown' system call.
> But I can't figure out how to audit when the socket is closed.
> Does the 'close' system call works? However all the file close events will
> also be auditing. That's not what I want.

_Which_ system call?  It may be close().  It may be dup2().  It may be
execve().  It may be exit().  It may be anything that kills a process
(signal delivery from somebody else, segfault, etc.).  It may be anything
that triggers AF_UNIX garbage collection.

And conversely, any of those might very well be _not_ the final close;
e.g. dup() + close() will leave the socket open - under a new file
descriptor number.  fork() + close() will do the same.  So will sticking
that descriptor into SCM_RIGHTS datagram and passing it over AF_UNIX
socket, to be received by somebody at later time - you can do close()
after having sent that and it won't do a damn thing to the reference that
went into the datagram.

Incidentally, that's a fine example of the reasons why syscall audit is useless
for almost anything other than CYA.  It's not that syscall tracing is useless -
strace can be quite useful, actually.  It's the bogus impression of coverage
in case of watching what live system does - a whole lot of events simply do
not map on "somebody had done a syscall with such and such arguments".

Re: How to audit socket close system call?

[LC Bruzenak]

[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]

On 01/08/2015 04:55 PM, Alexander Viro wrote:
> Incidentally, that's a fine example of the reasons why syscall audit is useless
> for almost anything other than CYA.  It's not that syscall tracing is useless -
> strace can be quite useful, actually.  It's the bogus impression of coverage
> in case of watching what live system does - a whole lot of events simply do
> not map on "somebody had done a syscall with such and such arguments".
All true & well put; thank you.
The CYA factor IS important. But the translation magic from user actions
to syscalls (and back - from intent to result) is where it gets interesting.
The forensics challenge with the data we have is what some of us are
grappling with now (forever).

LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]