[GSoC-18] Regression Test-Suite for Audit Framework [Week-2]

Aniket Pandey aniketp at freebsd.org
Mon May 28 02:10:30 UTC 2018

Hello all,

At the end of the week 2, as promised, I was able to finish off the tests
for network APIs and complete the remaining test cases for audit classes
concerned with File I/O and device management. I also studied about "Inter
Process Communication" within an Operating System and how best to audit the
syscalls present within IPC audit class. So a total of 115 atf-c(3)
test-cases spanning over 6 audit classes {fm, cl, nt, io, ex, ip} were
developed during this week.

Milestones and issues encountered
1) Fixing the panic mentioned in the previous mail, brought up another
consistent and reproducible kernel panic. This time, whenever auditd(8) was
already running and the system-wide audit mask was set as "pc" (process
control), trying to list the contents of a directory using "exa-0.8.0"
caused another panic. The stack trace showed the involvement of an audit
lookup function. ( https://pastebin.com/b68k27iw )

2) On trying to audit execve(2) system call, we noticed that even on the
successful invocation of execve, audit record showed
"return,failure : Unknown error" which was quite unexpected. On further
analysis, we concluded that since execve(2) overlays the calling process on
successful execution, the audit(4) doesn't get any return status so it
essentially prints out the exception case in the errno lookup here:

3) While writing tests for network socket system calls, I had to overcome a
unique challenge. Since Kyua executes every test-case as a separate process
and that it's not possible to share the state between the test cases, I had
to somehow integrate both client and server APIs within a single test case
body. Now the options I could think of were to either fork the client out
of the main process after listen(2) has been called, or simply use
different threads for both.

However, Alan suggested a much better approach, simply make the server
non-blocking and create the client socket right before connect(2) is
called. With the server waiting for connection by the time client calls a
connect(2), we would be able to get the successful connection within the
same program in a single thread. [ Note: Even though this method is
successful in FreeBSD, it sometimes returns EWOULDBLOCK in Linux ]

Although I could get a successful connection using this approach, I still
had to audit recv(2), recvfrom(2) which are blocking, after they
successfully receive data from their counterparts, i.e send(2) and
sendto(2). But since I was calling the recv(2) from the server which was
already non-blocking, I couldn't get a successful audit of these functions.

On further research, I came across some threads on reddit which mentioned
doing synchronous I/O multiplexing on the client socket using select(2) to
ensure that the socket is ready for reading, i.e recv(2), recvfrom(2) can
successfully exit. This allowed me to audit all possible scenarios of
network socket system calls! Here is the test-case which checks the audit
of recvfrom(2):

4) Post that, I've added about 51 test cases for system calls concerned
with manipulating message queues, shared memory segments and semaphore sets
as a part of IPC audit class. I would keep adding the tests and hopefully,
finish off "ip" audit events within a couple of days.

5) I've also created a differential revision on shifting "struct
auditpipe_ioctl_preselect" from <security/audit/audit_ioctl.h> to
<bsm/audit.h> since its members, i.e "au_mask_t" and "au_id_t" are defined
within the later header file. It is currently under review.

So far, I've been able to create 421 test-cases spanning over 11 test
programs for 107 system calls of {"fc", "fr", "fw", "fd", "fa", "fm", "cl",
"io", "ex", "nt", "ip"} audit classes in 8449 SLOC. The tests are passing
apart from a few expected failures from syscalls which are supposed to be
audited but are not. The test result can be seen here >

I'll hopefully be able to finish off my proposed work (explicit system call
testing) within a week and then I can work on testing some other important
aspects of the audit system as a stretch goal.

Bugs Reported (this week)
1) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228444 [Kernel panic
due to "exa"]
2) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228470 [ location of

Differential Revisions
1) https://reviews.freebsd.org/D15561

Thank you,
With Best Regards,
Aniket Pandey

P.S: The discussion regarding the project takes place on #audit-testing
channel on efnet. If anybody is interested in the discussions and would
like to suggest some improvements in the current approach, please feel free
to join the channel!

More information about the soc-status mailing list