Add tests for open(2) and openat(2) for "file-create" audit class

[aniketp]

Summary

The following changes add to the already existing 24 tests for fc "file-create" audit class which were introduced in D15286 and committed as rS334360. These 24 test-cases check the proper audit of open(2) and openat(2) for various file opening modes in both success and failure case.

Following modes were defined by the audit events list

• read - create
• write - create
• read - write - create
• read - create - trunc
• write - create - trunc
• read - write - create - trunc

The part create is common among these and it essentially conveys that creation of a file/link was involved, hence the class file-create

Test Plan

Execute make && make install from test/sys/audit.
Execute kyua test from /usr/tests/sys/audit. All testcases should succeed.

[asomers]

tests/sys/audit/file-create.c

569

Do you think you should add the syscall name to the regexes?

1104

Testing the full n^2 combination of flags creates a lot of test cases. Maybe you should just do a base test case plus one additional one for each flag.

[aniketp]

tests/sys/audit/file-create.c

569

No other syscall will have "read,creat" apart from open(2) or openat(2) in fc audit class.
Including the syscall name was pointless as it would unnecessarily increase regex length.
Also, the fileforaudit pin-points to the syscall triggered by the testcase

1104

Opening files in these modes it a separate audit event in itself and not just a combination. Also @rwatson, emphasized on testing all these audit events specified by open(2) and openat(2). So it would make sense to test these audit events I think.

The part like read,creat,trunc which I'm matching as the regex is present in the header token and not in the arguments, so it's like each opening mode is an audit events in itself.

[asomers]

tests/sys/audit/file-create.c

569

Yeah, I know that seeing "fileforaudit" in the audit trail guarantees that the syscall of concern got audited, but it still doesn't verify that the record contains all of the proper information. I'm asking if you think there's value in checking that the right syscall name is in the audit trail?

[aniketp]

tests/sys/audit/file-create.c

569

Yes, these tests don't check for anything apart from return value and the opening mode of a specific syscall.
We can have test cases for checking all the proper info in a syscall but currently my approach has been to ensure that the syscall got audited in both success and failure mode.

We can extend these test cases later on if checking for all proper information within an audit record.

I figured that it might not be important to check the syscall's name in case of open and openat as we already have the info about the opening mode. But I can add the syscall's name in the audit regex, no issues

[aniketp]

Add the following comment in the beginning of the test-program:

Note: open(2) and openat(2) have been tested in various combination of flags
with O_CREAT being common since all of them are separate auditable events
See: https://github.com/openbsm/openbsm/blob/master/etc/audit_event#L93

[asomers]

tests/sys/audit/file-create.c

32

FreeBSD's audit_event file is not necessarily equal to upstream OpenBSM's. You should only reference the FreeBSD file. And why didn't you test the non-O_CREAT events, too?

[aniketp]

tests/sys/audit/file-create.c

32

@asomers, I've created tests for all possible opening modes, but they all are in their respective audit classes. For file-create audit class, O_CREAT is required. And it is possible that same opening mode can be in multiple audit classes.
For ex.
open(path, O_RDWR) would be in file-read file-write (but not in file-create)
but open(O_RDONLY | O_CREAT | O_TRUNC) in file-read file-create file-delete but not in file-write

[aniketp]

Update the URL to audit event list to point to contrib/openbsm/etc/audit_events