socket_events improvements - non-blocking sockets, accept() syscalls

[alessandrogario]

Introduction

This PR adds support for the following two things:

1. accept and accept4 syscalls, showing all incoming connections.
2. Operations on non-blocking sockets.

Why

When audit emits a syscall record, the success parameter is set according to the exit code of the function. The issue with this is that when operating on non-blocking sockets, certain syscalls (connect, bind) will immediately return -1 with an errno value of EINPROGRESS. This causes potentially valid events to be dropped.

You can see how common non-blocking sockets are by using strace on tools like curl, wget or netcat.

Note that the bind() syscall is not enough to look for incoming connections, as you can easily fool event collection by setting a socket in listen() without binding. You can then get the port using getsockname().

Changes

1. Syscall events are no longer discarded by the Audit publisher. This gives a chance to the subscribers to decide what to do. Currently, only the socket_events table is accepting these events.
2. The socket_events table is now able to monitor for accept() and accept4() syscalls.
3. A new flag named audit_disable_accept_syscalls has been added, to optionally let the user disable accept() and accept4() syscall handling. By default, it is set to false.

Schema

The success column is now deprecated, and has been replaced by the status column. Here's how it works:

accept(), accept4() events

This event is not affected by the blocking or non-blocking attribute of the sockets. It is only emitted if the syscall has succeeded (the status field will always contain succeeded).

bind(), connect() events

This event is affected by the non-blocking attribute of the socket. When the success field in the Audit record is set to yes, then this operation has definitely succeeded, and the socket is blocking. In this case, the status field will contain succeeded.

When the success field in the Audit record is set to "no" however, we don't know for sure what happened:

1. The socket could be blocking, and the operation has failed.
2. The socket is non-blocking, and the operation has either failed or succeeded at a later time.

Since there is no way (without tracking socket states) to determine the outcome, the status field will contain unknown.

Related issues

By implementing the new tests, this should also address the following issue: #4930 - Create tests for the table socket_events.

[muffins]

ok to test

[theopolis]

jenkins test macos

[theopolis]

Heads up, we are going to close older PRs to help with project organization and focus. If you are still eager to land your changes please feel welcomed to re-open the request. If you feel like you were waiting for answers or a review from other project contributors please mention me and I'll take a look as soon as possible.