tests: sys/capsicum/functional requires mqueuefs

Skip this test if mqueuefs isn't loaded. Unfortunately, that will skip
the entire googletest test program, including test cases that don't
require m

tests: sys/capsicum/functional requires mqueuefs

Skip this test if mqueuefs isn't loaded. Unfortunately, that will skip
the entire googletest test program, including test cases that don't
require mqueuefs. But the test's own skipping logic doesn't work, and
we don't yet have a googletest-compatible require_kmods() function.

MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: emaste, ngie
Differential Revision: https://reviews.freebsd.org/D54902

show more ...

capsicum-test: Move out of contrib

Google developed the Capsicum unit test suite[1] as part of the
Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD
and unit tests developed as

capsicum-test: Move out of contrib

Google developed the Capsicum unit test suite[1] as part of the
Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD
and unit tests developed as part of the initial Capsicum-Linux port.

Capsicum-Linux was archived as of October 31, 2022 and is no longer
being maintained. FreeBSD is currently the only consumer of and
contributor to the test suite. Move the src into tests/sys/capsicum to
simplify ongoing maintenance.

The makefiles were deleted as we (continue to) use the existing bespoke
FreeBSD Makefile, and CONTRIBUTING.md was removed as the Google CLA is
no longer applicable.

[1] https://github.com/google/capsicum-test
[2] https://github.com/google/capsicum-linux

Reviewed by: asomers, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54917

show more ...

capsicum tests: Serialize functional tests

The test suite runs the same tests twice, as different users, and these
can trample over each other when run in parallel, causing spurious test
failures.

capsicum tests: Serialize functional tests

The test suite runs the same tests twice, as different users, and these
can trample over each other when run in parallel, causing spurious test
failures.

MFC after: 1 week

show more ...

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

capsicum: add tests for copy_file_range

Reviewed by: emaste, theraven, kib, markj (all previous version)
Differential Revision: https://reviews.freebsd.org/D41967

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Fix MK_TESTS build with MK_ASAN/MK_UBSAN

Reviewed By: markj
Differential Revision: https://reviews.freebsd.org/D31049

Update capsicum-test to git commit f4d97414d48b8f8356b971ab9f45dc5c70d53c40

This includes various fixes that I submitted recently such as updating the
pdkill() tests for the actual implemented behav

Update capsicum-test to git commit f4d97414d48b8f8356b971ab9f45dc5c70d53c40

This includes various fixes that I submitted recently such as updating the
pdkill() tests for the actual implemented behaviour
(https://github.com/google/capsicum-test/pull/53) and lots of changes to
avoid calling sleep() and replacing it with reliable synchronization
(pull requests 49,51,52,53,54). This should make the testsuite more reliable
when running on Jenkins. Additionally, process status is now retrieved using
libprocstat instead of running `ps` and parsing the output
(https://github.com/google/capsicum-test/pull/50). This fixes one previously
failing test and speeds up execution.

Overall, this update reduces the total runtime from ~60s to about 4-5 seconds.

show more ...

Make capsicum test cases fine-grained

Add a wrapping script to use ATF to run tests written with Googletest
one by one. This helps locating and tracking the failing case in CI easier.

This is a tem

Make capsicum test cases fine-grained

Add a wrapping script to use ATF to run tests written with Googletest
one by one. This helps locating and tracking the failing case in CI easier.

This is a temporarily solution while Googletest support in Kyua is developing.
We will revert this once Kyua+Googletest integration is ready.

Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25896

show more ...

Do a sweep and remove most WARNS=6 settings

Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas an

Do a sweep and remove most WARNS=6 settings

Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.

Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.

show more ...

MFHead@r345880

Integrate capsicum-test into the FreeBSD test suite

This change takes capsicum-test from upstream and applies some local changes to make the
tests work on FreeBSD when executed via Kyua.

The local

Integrate capsicum-test into the FreeBSD test suite

This change takes capsicum-test from upstream and applies some local changes to make the
tests work on FreeBSD when executed via Kyua.

The local modifications are as follows:
1. Make `OpenatTest.WithFlag` pass with the new dot-dot lookup behavior in FreeBSD 12.x+.
2. capsicum-test references a set of helper binaries: `mini-me`, `mini-me.noexec`, and
`mini-me.setuid`, as part of the execve/fexecve tests, via execve, fexecve, and open.
It achieves this upstream by assuming `mini-me*` is in the current directory, however,
in order for Kyua to execute `capsicum-test`, it needs to provide a full path to
`mini-me*`. In order to achieve this, I made `capsicum-test` cache the executable's
path from argv[0] in main(..) and use the cached value to compute the path to
`mini-me*` as part of the execve/fexecve testcases.
3. The capsicum-test test suite assumes that it's always being run on CAPABILITIES enabled
kernels. However, there's a chance that the test will be run on a host without a
CAPABILITIES enabled kernel, so we must check for the support before running the tests.
The way to achieve this is to add the relevant `feature_present("security_capabilities")`
check to SetupEnvironment::SetUp() and skip the tests when the support is not available.
While here, add a check for `kern.trap_enotcap` being enabled. As noted by markj@ in
https://github.com/google/capsicum-test/issues/23, this sysctl being enabled can trigger
non-deterministic failures. Therefore, the tests should be skipped if this sysctl is
enabled.

All local changes have been submitted to the capsicum-test project
(https://github.com/google/capsicum-test) and are in various stages of review.
Please see the following pull requests for more details:
1. https://github.com/google/capsicum-test/pull/35
2. https://github.com/google/capsicum-test/pull/41
3. https://github.com/google/capsicum-test/pull/42

Reviewed by: asomers
Discussed with: emaste, markj
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19758

show more ...

Skip test if feature security_capabilities is not available

PR: 236863
Approved by: asomers
MFC after: 1 month
Sponsored by: Netflix

capsicum tests: Serialize functional tests

The test suite runs the same tests twice, as different users, and these
can trample over each other when run in parallel, causing spurious test
failures.

capsicum tests: Serialize functional tests

The test suite runs the same tests twice, as different users, and these
can trample over each other when run in parallel, causing spurious test
failures.

MFC after: 1 week

show more ...

Remove residual blank line at start of Makefile

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

capsicum: add tests for copy_file_range

Reviewed by: emaste, theraven, kib, markj (all previous version)
Differential Revision: https://reviews.freebsd.org/D41967

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Fix MK_TESTS build with MK_ASAN/MK_UBSAN

Reviewed By: markj
Differential Revision: https://reviews.freebsd.org/D31049

Update capsicum-test to git commit f4d97414d48b8f8356b971ab9f45dc5c70d53c40

This includes various fixes that I submitted recently such as updating the
pdkill() tests for the actual implemented behav

Update capsicum-test to git commit f4d97414d48b8f8356b971ab9f45dc5c70d53c40

This includes various fixes that I submitted recently such as updating the
pdkill() tests for the actual implemented behaviour
(https://github.com/google/capsicum-test/pull/53) and lots of changes to
avoid calling sleep() and replacing it with reliable synchronization
(pull requests 49,51,52,53,54). This should make the testsuite more reliable
when running on Jenkins. Additionally, process status is now retrieved using
libprocstat instead of running `ps` and parsing the output
(https://github.com/google/capsicum-test/pull/50). This fixes one previously
failing test and speeds up execution.

Overall, this update reduces the total runtime from ~60s to about 4-5 seconds.

show more ...

Make capsicum test cases fine-grained

Add a wrapping script to use ATF to run tests written with Googletest
one by one. This helps locating and tracking the failing case in CI easier.

This is a tem

Make capsicum test cases fine-grained

Add a wrapping script to use ATF to run tests written with Googletest
one by one. This helps locating and tracking the failing case in CI easier.

This is a temporarily solution while Googletest support in Kyua is developing.
We will revert this once Kyua+Googletest integration is ready.

Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25896

show more ...

Do a sweep and remove most WARNS=6 settings

Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas an

Do a sweep and remove most WARNS=6 settings

Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.

Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.

show more ...

MFHead@r345880

Integrate capsicum-test into the FreeBSD test suite

This change takes capsicum-test from upstream and applies some local changes to make the
tests work on FreeBSD when executed via Kyua.

The local

Integrate capsicum-test into the FreeBSD test suite

This change takes capsicum-test from upstream and applies some local changes to make the
tests work on FreeBSD when executed via Kyua.

The local modifications are as follows:
1. Make `OpenatTest.WithFlag` pass with the new dot-dot lookup behavior in FreeBSD 12.x+.
2. capsicum-test references a set of helper binaries: `mini-me`, `mini-me.noexec`, and
`mini-me.setuid`, as part of the execve/fexecve tests, via execve, fexecve, and open.
It achieves this upstream by assuming `mini-me*` is in the current directory, however,
in order for Kyua to execute `capsicum-test`, it needs to provide a full path to
`mini-me*`. In order to achieve this, I made `capsicum-test` cache the executable's
path from argv[0] in main(..) and use the cached value to compute the path to
`mini-me*` as part of the execve/fexecve testcases.
3. The capsicum-test test suite assumes that it's always being run on CAPABILITIES enabled
kernels. However, there's a chance that the test will be run on a host without a
CAPABILITIES enabled kernel, so we must check for the support before running the tests.
The way to achieve this is to add the relevant `feature_present("security_capabilities")`
check to SetupEnvironment::SetUp() and skip the tests when the support is not available.
While here, add a check for `kern.trap_enotcap` being enabled. As noted by markj@ in
https://github.com/google/capsicum-test/issues/23, this sysctl being enabled can trigger
non-deterministic failures. Therefore, the tests should be skipped if this sysctl is
enabled.

All local changes have been submitted to the capsicum-test project
(https://github.com/google/capsicum-test) and are in various stages of review.
Please see the following pull requests for more details:
1. https://github.com/google/capsicum-test/pull/35
2. https://github.com/google/capsicum-test/pull/41
3. https://github.com/google/capsicum-test/pull/42

Reviewed by: asomers
Discussed with: emaste, markj
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19758

show more ...

Skip test if feature security_capabilities is not available

PR: 236863
Approved by: asomers
MFC after: 1 month
Sponsored by: Netflix

Disable connectat/bindat with AT_FDCWD in capmode

Previously it was possible to connect a socket (which had the
CAP_CONNECT right) by calling "connectat(AT_FDCWD, ...)" even in
capabilties mode. Th

Disable connectat/bindat with AT_FDCWD in capmode

Previously it was possible to connect a socket (which had the
CAP_CONNECT right) by calling "connectat(AT_FDCWD, ...)" even in
capabilties mode. This combination should be treated the same as a call
to connect (i.e. forbidden in capabilities mode). Similarly for bindat.

Disable connectat/bindat with AT_FDCWD in capabilities mode, fix up the
documentation and add tests.

PR: 222632
Submitted by: Jan Kokemüller <jan.kokemueller@gmail.com>
Reviewed by: Domagoj Stolfa
MFC after: 1 week
Relnotes: Yes
Differential Revision: https://reviews.freebsd.org/D15221

show more ...