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.

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(a)redhat.com&gt; 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit

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".