| Age | Commit message (Collapse) | Author |
|---|
|
Two previously-untested syscalls now have integration coverage:
- getrandom (Security family, READ_CLASSIFIED): new security-getrandom
scenario fills a 32-byte buffer via unix.Getrandom, looping past any
signal-interrupted short reads so the cumulative byte count is strictly
positive. TestSecurityGetrandom asserts enter_getrandom MinCount>=1,
bytes>=1 (locking in the READ byte-count classification end-to-end), and
a positive duration.
- flock (FamilyFS, KindFd@args[0], UNCLASSIFIED): new flock-basic scenario
opens a temp file, takes LOCK_EX then LOCK_UN via syscall.Flock, and
closes it. TestFlockBasic asserts enter_flock with PathContains the temp
filename, confirming the fd resolves to the file path via the procfd
cache.
Both scenarios use raw unix/syscall calls so the exact sys_enter tracepoints
fire, and are registered in cmd/ioworkload/scenarios.go.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Extend the existing security-landlock scenario to also exercise
landlock_add_rule in-process. After creating the ruleset fd, the
scenario builds a struct landlock_path_beneath_attr (allowed_access =
LANDLOCK_ACCESS_FS_READ_FILE, parent_fd = open("/", O_PATH)) and calls
landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, &attr, 0)
(syscall nr 445), then closes both fds.
landlock_add_rule is unprivileged and has no process-wide side effects
(it only builds a ruleset that is never enforced), so it is safe to run
in the shared workload process. The call is issued unconditionally even
when ruleset creation fails: sys_enter_landlock_add_rule fires before
the kernel validates the fd, so the enter tracepoint is captured
regardless of whether Landlock is enabled, matching create_ruleset
coverage. ret is UNCLASSIFIED (0/-1, not a byte count).
TestSecurityLandlockCreateRuleset now adds landlock_add_rule to the
trace-arg set and asserts enter_landlock_add_rule MinCount>=1 plus a
positive event duration, capturing ruleset_fd at args[0] (KindFd).
landlock_restrict_self (ci0) is intentionally NOT covered here: it would
require a traced child subprocess, which the integration harness cannot
support (it filters by the single workload PID at the BPF layer).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
Add a Security-family end-to-end scenario + test for
landlock_create_ruleset, which was previously untested.
The new securityLandlockCreateRuleset scenario (registered as
"security-landlock") builds a minimal valid struct
landlock_ruleset_attr{handled_access_fs=LANDLOCK_ACCESS_FS_READ_FILE},
calls landlock_create_ruleset(&attr, sizeof(attr), 0) via raw syscall
(nr=444 on amd64/arm64), and closes the returned ruleset fd. It
tolerates ENOSYS/EOPNOTSUPP (kernel < 5.13 or Landlock LSM disabled)
since the sys_enter tracepoint fires before any such error. It
deliberately never calls landlock_restrict_self, which would
irreversibly sandbox the shared integration-test runner.
TestSecurityLandlockCreateRuleset asserts enter_landlock_create_ruleset
MinCount>=1 and positive duration unconditionally, plus conditional
"landlockfd:" path-prefix assertions on the create/close pair with an
open/close path-stability check.
Verified: TEST_NAME=TestSecurityLandlockCreateRuleset mage testWithName
PASS (kernel 7.0.9); mage build, go build ./cmd/ioworkload/, and
go vet ./integrationtests/ all clean.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
|
|
|
|
|
|
