Re: audit syscall information.
On Sat, Apr 23, 2005 at 12:56:43AM +1000, David Woodhouse wrote:
On the call two weeks ago I pointed out the potential race condition;
if
we log the target of the pointer at syscall entry time, another
userspace thread may change the contents of memory at that address by
the time the syscall actually executes and calls copy_from_user(). This
is why we have to add hooks such as the ones in the IPC code, instead of
just doing extra logging in audit_syscall_entry() for certain syscalls.
Yes, this race condition has been a frequent topic of discussion, and the
current LAF code uses a third completely different approach to avoid it,
the 2.4 and 2.6 LAuS code had each used other methods for this.
Just to make sure, I want to repeat the question which nobody deigned
to
answer at the time: are there any more system calls for which we should
be adding hooks to log extra information, because the information
currently recorded is not sufficient for CAPP?
For CAPP, the interesting part here is the object identity, which is
handled by the current code for filesystem objects, and is easy for IPC
objects since the numerical ID is available in a register on the
architectures I'm familiar with.
(The definition of "object" of course depends on the specific security
target, CAPP doesn't define that. For unixoid systems, these are usually
filesystem and IPC objects, plus in some cases the TCP/UDP port number
and address for bound sockets.)
One additional piece of information needed would be the struct sockaddr
(port number and address) used by bind(), this would also be useful (but
not required) for connect().
Note that CAPP does not specifically require that the audit record
contains all information for the system call, such as the specific
permission changes made by a shmctl call. Having that information
available is obviously useful (and requires collecting data from
userspace), but you could claim CAPP compliance without auditing it as
long as you have the required fields (success/failure, object identity
where applicable, subject (process ID), and user identity (login UID).
-Klaus