Date: Tue, 10 Jul 2018 14:53:43 +0530 From: Aniket Pandey <aniketp@freebsd.org> To: soc-status@freebsd.org Cc: Alan Somers <asomers@freebsd.org>, George Neville-Neil <gnn@neville-neil.com>, robert.watson@cl.cam.ac.uk Subject: [GSoC-18] Regression Test-Suite for Audit Framework [Week-8] Message-ID: <CADsqe1DWGcWW6RYtORsapYiSrg_=DHv%2BW78_ouYWc1T_gHtj%2Bg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADsqe1DWGcWW6RYtORsapYiSrg_=DHv%2BW78_ouYWc1T_gHtj%2Bg>