Date: Mon, 11 Jun 2018 18:35:29 +0530 From: Aniket Pandey <aniketp@freebsd.org> To: soc-status@freebsd.org, asomers@freebsd.org, George Neville-Neil <gnn@neville-neil.com>, robert.watson@cl.cam.ac.uk, gavin@freebsd.org Subject: [GSoC-18] Regression Test-Suite for Audit Framework [Week-4] Message-ID: <CADsqe1B-6GB_mjsD%2BV0EezkHH=Kus0iD9sey9hvc%2BzyDxnNx0g@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello all, In this week, I was mostly involved in optimising the test cases for open(2) and openat(2), since their various modes of operation are classified as separate auditable events, and some of those modes pass multiple audit class filters. With regards to the aforementioned possibility, the total number of atf-c(3) test cases would be about 192, which is a huge number. To keep it short, I selected "file-read" and "file-write" as the baseline and then using the macro definition, generated the tests for open(2) and friends. Example syntax: #define OPEN_AT_TC_DEFINE(mode, regex, flag, class) \ ATF_TC_WITH_CLEANUP(open_ ## mode ## _success); \ I initially had a few problems, which consumed a lot of time in debugging. For example, I had to pass the flag arguments to the macro definition, e.g "O_CREAT | O_RDWR". This for some reason was not detected as an integer argument and the test case build failed consistently. However, explicitly specifying the flag as a signed integer did the magic, also at the same time I was able to include "flag" in the test case description by stringifying it with the help of C preprocessor. The test-program was merged in CURRENT with r334668 <https://reviews.freebsd.org/rS334668>. Next major issue, which actually took most part of the week, was to figure out why execve(2) and fexecve(2) returned "Unknown error: 201" even though the invocation was successful. For this, I had to dive deep into the kernel implementation of audit(4) and try to understand how exactly is the return status of a system call determined. My initial thoughts were that there must be some default function implementation which does the job of assigning the errno to every instance of syscall. Turns out, there were two macros in "sys/subr_syscall.c", which enclose the error retrieval snippet: AUDIT_SYSCALL_ENTER(sa->code, td); error = (sa->callp->sy_call)(td, sa->args); AUDIT_SYSCALL_EXIT(error, td); After some further research, I figured out that it is not possible to intrinsically change the return behavior of execve(2), but I can in-fact refactor the logic in errno lookup in "security/audit/audit_bsm.c" which could change the errno specifically to 0 for execve(2) and friends. Post that. I created a revision for test-case of stat(2), fstat(2), lstat(2) and fstatat(2) in "file-attribute-access" audit class which was merged without any hassle with r334933 <https://reviews.freebsd.org/rS334933>. Currently, the tests for system calls concerned with getting the statistics of mounted filesystems is under review in D15750 <https://reviews.freebsd.org/D15750>. Also, as a stretch goal, I created ATF-SH(3) test program for the audit viewer utility, praudit(1) and I'm currently working on auditreduce(1): praudit/praudit_test.sh <https://github.com/aniketp/AuditTestSuite/blob/master/praudit/praudit_test.sh>; . Thank you, With best regards, Aniket Pandey Main Repository: https://github.com/aniketp/AuditTestSuite Project Wiki: https://wiki.freebsd.org/SummerOfCode2018Projects/RegressionTestSuiteForAuditFramework Audit TestSuite within FreeBSD src: https://github.com/freebsd/freebsd/tree/master/tests/sys/audit
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADsqe1B-6GB_mjsD%2BV0EezkHH=Kus0iD9sey9hvc%2BzyDxnNx0g>