Fwd: [GSoC-18] Regression Test-Suite for Audit Framework [Week-8]

Aniket Pandey aniketp at freebsd.org
Tue Jul 10 10:20:25 UTC 2018


Hello all,

I had been traveling for the last couple of days so couldn't update you all
about my progress earlier. This week, I was able to create regression tests
for sysctl(3), sysarch(2), cap_getmode(2), cap_enter(2) completely and
audit(2) & jail(2) in failure mode. Also, in the previous mail, I had
mentioned about setpriority(2) being in the "miscellaneous" audit class.
Well, it turns out that I had not carefully looked at the section in which
the specific event-class mapping was listed. setpriority(2) is exclusively
a process-control system call. It was mentioned under the section of
deprecated Darwin audit events which might conflict with Solaris mapping,
later on, so that essentially rules out setpriority(2) being a
miscellaneous audit event.

For sysarch(2), I had to consider different architectures on which it would
be called. sysarch(2) is included within <machine/sysarch.h> which in turn
includes the header for respective architecture, for my case,
<x86/sysarch.h>. On further analysis of supported machine instructions, I
could only come up with possible testing scenarios for AMD64, i386, ARM,
and MIPS. For Sparc64, ARM64 & PowerPC, I could either not find any safe
machine instruction or none existed for them.

To write the tests, I followed the strategy of using the macros which were
defined in the <machine/sysarch.h>, that would generate only those tests
which were supported by the architecture in which the tests were compiled.
All macros retrieved some info about the system, so they can be considered
safe. Currently, the tests are under review and you can find the respective
macro used here[1].

cap_getmode(2) and sysctl(3) were cakewalks as I had to just check whether
Capsicum is enabled in the system or not (for the former) and use the
standard sysctl to retrieve the maximum allowed processes using
KERN_MAXPROC (for the later).

With cap_enter(2), I again faced the intermittency issues. With a lot of
debugging and help from Alan, we figured out that auditpipe(4) gets
buffered when capability mode is entered. Hence, auditpipe does not show
anything after fork(2) is called (Yes, I had to call cap_enter() from a
child process since we can't put the main test in capability mode :P). A
solution was to flush the auditpipe(4) right after cap_enter(2) is called,
using a provided ioctl AUDITPIPE_FLUSH, that allowed cap_enter(2) to show
up after the noise is cleaned. The updated tests for capability mode
syscalls can be found here [2].

In the coming weeks, I'll try to convert the regression tests[3] for
auditpipe(4) itself in ATF. And will have a look at the ways in which we
can test auditdistd(8) and auditreduce(1).

Thank you,
With best regards,
Aniket Pandey

[1] https://reviews.freebsd.org/D16116

[2] https://reviews.freebsd.org/D16099

[3] https://github.com/freebsd/freebsd/blob/master/
tools/regression/audit/audit_pipe_ioctl/audit_pipe_ioctl.c


More information about the soc-status mailing list