* How to audit socket close system call? @ 2014-12-19 6:06 Jie Cui 2014-12-19 14:37 ` Steve Grubb 2015-01-08 22:55 ` Alexander Viro 0 siblings, 2 replies; 6+ messages in thread From: Jie Cui @ 2014-12-19 6:06 UTC (permalink / raw) To: linux-audit [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to audit socket close system call? 2014-12-19 6:06 How to audit socket close system call? Jie Cui @ 2014-12-19 14:37 ` Steve Grubb 2014-12-20 19:39 ` Hassan Sultan 2015-01-08 22:55 ` Alexander Viro 1 sibling, 1 reply; 6+ messages in thread From: Steve Grubb @ 2014-12-19 14:37 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to audit socket close system call? 2014-12-19 14:37 ` Steve Grubb @ 2014-12-20 19:39 ` Hassan Sultan 2014-12-21 16:04 ` Steve Grubb 0 siblings, 1 reply; 6+ messages in thread From: Hassan Sultan @ 2014-12-20 19:39 UTC (permalink / raw) To: linux-audit, Steve Grubb 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to audit socket close system call? 2014-12-20 19:39 ` Hassan Sultan @ 2014-12-21 16:04 ` Steve Grubb 0 siblings, 0 replies; 6+ messages in thread From: Steve Grubb @ 2014-12-21 16:04 UTC (permalink / raw) To: Hassan Sultan; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to audit socket close system call? 2014-12-19 6:06 How to audit socket close system call? Jie Cui 2014-12-19 14:37 ` Steve Grubb @ 2015-01-08 22:55 ` Alexander Viro 2015-01-09 18:22 ` LC Bruzenak 1 sibling, 1 reply; 6+ messages in thread From: Alexander Viro @ 2015-01-08 22:55 UTC (permalink / raw) To: Jie Cui; +Cc: linux-audit 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". ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to audit socket close system call? 2015-01-08 22:55 ` Alexander Viro @ 2015-01-09 18:22 ` LC Bruzenak 0 siblings, 0 replies; 6+ messages in thread From: LC Bruzenak @ 2015-01-09 18:22 UTC (permalink / raw) To: linux-audit [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-09 18:23 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-12-19 6:06 How to audit socket close system call? Jie Cui 2014-12-19 14:37 ` Steve Grubb 2014-12-20 19:39 ` Hassan Sultan 2014-12-21 16:04 ` Steve Grubb 2015-01-08 22:55 ` Alexander Viro 2015-01-09 18:22 ` LC Bruzenak
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).