kernel/tools/testing/selftests/landlock/fs_test.c, branch linux-6.2.y

selftests/landlock: Skip overlayfs tests when not supported

2023-03-10T08:29:31Z

commit 366617a69e60610912836570546f118006ebc7cb upstream. overlayfs may be disabled in the kernel configuration, causing related tests to fail. Check that overlayfs is supported at runtime, so we can skip layout2_overlay.* accordingly. Signed-off-by: Jeff Xu Reviewed-by: Guenter Roeck Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230113053229.1281774-2-jeffxu@google.com [mic: Reword comments and constify variables] Signed-off-by: Mickaël Salaün Signed-off-by: Greg Kroah-Hartman

selftests/landlock: Test ftruncate on FDs created by memfd_create(2)

2022-10-19T07:01:47Z

All file descriptors that are truncatable need to have the Landlock access rights set correctly on the file's Landlock security blob. This is also the case for files that are opened by other means than open(2). Test coverage for security/landlock is 94.7% of 838 lines according to gcc/gcov-11. Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20221018182216.301684-10-gnoack3000@gmail.com [mic: Add test coverage in commit message] Signed-off-by: Mickaël Salaün

selftests/landlock: Test FD passing from restricted to unrestricted processes

2022-10-19T07:01:46Z

A file descriptor created in a restricted process carries Landlock restrictions with it which will apply even if the same opened file is used from an unrestricted process. This change extracts suitable FD-passing helpers from base_test.c and moves them to common.h. We use the fixture variants from the ftruncate fixture to exercise the same scenarios as in the open_and_ftruncate test, but doing the Landlock restriction and open() in a different process than the ftruncate() call. Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20221018182216.301684-9-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün

selftests/landlock: Test open() and ftruncate() in multiple scenarios

2022-10-19T07:01:44Z

This test uses multiple fixture variants to exercise a broader set of scnenarios. Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20221018182216.301684-7-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün

selftests/landlock: Test file truncation support

2022-10-19T07:01:44Z

These tests exercise the following truncation operations: * truncate() (truncate by path) * ftruncate() (truncate by file descriptor) * open with the O_TRUNC flag * special case: creat(), which is open with O_CREAT|O_WRONLY|O_TRUNC. in the following scenarios: * Files with read, write and truncate rights. * Files with read and truncate rights. * Files with the truncate right. * Files without the truncate right. In particular, the following scenarios are enforced with the test: * open() with O_TRUNC requires the truncate right, if it truncates a file. open() already checks security_path_truncate() in this case, and it required no additional check in the Landlock LSM's file_open hook. * creat() requires the truncate right when called with an existing filename. * creat() does *not* require the truncate right when it's creating a new file. * ftruncate() requires that the file was opened by a thread that had the truncate right for the file at the time of open(). (The rights are carried along with the opened file.) Signed-off-by: Günther Noack Link: https://lore.kernel.org/r/20221018182216.301684-6-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün

landlock: Support file truncation

2022-10-19T07:01:44Z

Introduce the LANDLOCK_ACCESS_FS_TRUNCATE flag for file truncation. This flag hooks into the path_truncate, file_truncate and file_alloc_security LSM hooks and covers file truncation using truncate(2), ftruncate(2), open(2) with O_TRUNC, as well as creat(). This change also increments the Landlock ABI version, updates corresponding selftests, and updates code documentation to document the flag. In security/security.c, allocate security blobs at pointer-aligned offsets. This fixes the problem where one LSM's security blob can shift another LSM's security blob to an unaligned address (reported by Nathan Chancellor). The following operations are restricted: open(2): requires the LANDLOCK_ACCESS_FS_TRUNCATE right if a file gets implicitly truncated as part of the open() (e.g. using O_TRUNC). Notable special cases: * open(..., O_RDONLY|O_TRUNC) can truncate files as well in Linux * open() with O_TRUNC does *not* need the TRUNCATE right when it creates a new file. truncate(2) (on a path): requires the LANDLOCK_ACCESS_FS_TRUNCATE right. ftruncate(2) (on a file): requires that the file had the TRUNCATE right when it was previously opened. File descriptors acquired by other means than open(2) (e.g. memfd_create(2)) continue to support truncation with ftruncate(2). Cc: Nathan Chancellor Signed-off-by: Günther Noack Acked-by: Paul Moore (LSM) Link: https://lore.kernel.org/r/20221018182216.301684-5-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün

landlock: Fix file reparenting without explicit LANDLOCK_ACCESS_FS_REFER

2022-09-02T13:29:08Z

This change fixes a mis-handling of the LANDLOCK_ACCESS_FS_REFER right when multiple rulesets/domains are stacked. The expected behaviour was that an additional ruleset can only restrict the set of permitted operations, but in this particular case, it was potentially possible to re-gain the LANDLOCK_ACCESS_FS_REFER right. With the introduction of LANDLOCK_ACCESS_FS_REFER, we added the first globally denied-by-default access right. Indeed, this lifted an initial Landlock limitation to rename and link files, which was initially always denied when the source or the destination were different directories. This led to an inconsistent backward compatibility behavior which was only taken into account if no domain layer were using the new LANDLOCK_ACCESS_FS_REFER right. However, when restricting a thread with a new ruleset handling LANDLOCK_ACCESS_FS_REFER, all inherited parent rulesets/layers not explicitly handling LANDLOCK_ACCESS_FS_REFER would behave as if they were handling this access right and with all their rules allowing it. This means that renaming and linking files could became allowed by these parent layers, but all the other required accesses must also be granted: all layers must allow file removal or creation, and renaming and linking operations cannot lead to privilege escalation according to the Landlock policy. See detailed explanation in commit b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER"). To say it another way, this bug may lift the renaming and linking limitations of the initial Landlock version, and a same ruleset can enforce different restrictions depending on previous or next enforced ruleset (i.e. inconsistent behavior). The LANDLOCK_ACCESS_FS_REFER right cannot give access to data not already allowed, but this doesn't follow the contract of the first Landlock ABI. This fix puts back the limitation for sandboxes that didn't opt-in for this additional right. For instance, if a first ruleset allows LANDLOCK_ACCESS_FS_MAKE_REG on /dst and LANDLOCK_ACCESS_FS_REMOVE_FILE on /src, renaming /src/file to /dst/file is denied. However, without this fix, stacking a new ruleset which allows LANDLOCK_ACCESS_FS_REFER on / would now permit the sandboxed thread to rename /src/file to /dst/file . This change fixes the (absolute) rule access rights, which now always forbid LANDLOCK_ACCESS_FS_REFER except when it is explicitly allowed when creating a rule. Making all domain handle LANDLOCK_ACCESS_FS_REFER was an initial approach but there is two downsides: * it makes the code more complex because we still want to check that a rule allowing LANDLOCK_ACCESS_FS_REFER is legitimate according to the ruleset's handled access rights (i.e. ABI v1 != ABI v2); * it would not allow to identify if the user created a ruleset explicitly handling LANDLOCK_ACCESS_FS_REFER or not, which will be an issue to audit Landlock. Instead, this change adds an ACCESS_INITIALLY_DENIED list of denied-by-default rights, which (only) contains LANDLOCK_ACCESS_FS_REFER. All domains are treated as if they are also handling this list, but without modifying their fs_access_masks field. A side effect is that the errno code returned by rename(2) or link(2) *may* be changed from EXDEV to EACCES according to the enforced restrictions. Indeed, we now have the mechanic to identify if an access is denied because of a required right (e.g. LANDLOCK_ACCESS_FS_MAKE_REG, LANDLOCK_ACCESS_FS_REMOVE_FILE) or if it is denied because of missing LANDLOCK_ACCESS_FS_REFER rights. This may result in different errno codes than for the initial Landlock version, but this approach is more consistent and better for rename/link compatibility reasons, and it wasn't possible before (hence no backport to ABI v1). The layout1.rename_file test reflects this change. Add 4 layout1.refer_denied_by_default* test suites to check that the behavior of a ruleset not handling LANDLOCK_ACCESS_FS_REFER (ABI v1) is unchanged even if another layer handles LANDLOCK_ACCESS_FS_REFER (i.e. ABI v1 precedence). Make sure rule's absolute access rights are correct by testing with and without a matching path. Add test_rename() and test_exchange() helpers. Extend layout1.inval tests to check that a denied-by-default access right is not necessarily part of a domain's handled access rights. Test coverage for security/landlock is 95.3% of 599 lines according to gcc/gcov-11. Fixes: b91c3e4ea756 ("landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER") Reviewed-by: Paul Moore Reviewed-by: Günther Noack Link: https://lore.kernel.org/r/20220831203840.1370732-1-mic@digikod.net Cc: stable@vger.kernel.org [mic: Constify and slightly simplify test helpers] Signed-off-by: Mickaël Salaün

selftests/landlock: Add 11 new test suites dedicated to file reparenting

2022-05-23T11:27:59Z

These test suites try to check all edge cases for directory and file renaming or linking involving a new parent directory, with and without LANDLOCK_ACCESS_FS_REFER and other access rights. layout1: * reparent_refer: Tests simple FS_REFER usage. * reparent_link: Tests a mix of FS_MAKE_REG and FS_REFER with links. * reparent_rename: Tests a mix of FS_MAKE_REG and FS_REFER with renames and RENAME_EXCHANGE. * reparent_exdev_layers_rename1/2: Tests renames with two layers. * reparent_exdev_layers_exchange1/2/3: Tests exchanges with two layers. * reparent_remove: Tests file and directory removal with rename. * reparent_dom_superset: Tests access partial ordering. layout1_bind: * reparent_cross_mount: Tests FS_REFER propagation across mount points. Test coverage for security/landlock is 95.4% of 604 lines according to gcc/gcov-11. Cc: Paul Moore Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20220506161102.525323-9-mic@digikod.net

landlock: Add support for file reparenting with LANDLOCK_ACCESS_FS_REFER

2022-05-23T11:27:59Z

Add a new LANDLOCK_ACCESS_FS_REFER access right to enable policy writers to allow sandboxed processes to link and rename files from and to a specific set of file hierarchies. This access right should be composed with LANDLOCK_ACCESS_FS_MAKE_* for the destination of a link or rename, and with LANDLOCK_ACCESS_FS_REMOVE_* for a source of a rename. This lift a Landlock limitation that always denied changing the parent of an inode. Renaming or linking to the same directory is still always allowed, whatever LANDLOCK_ACCESS_FS_REFER is used or not, because it is not considered a threat to user data. However, creating multiple links or renaming to a different parent directory may lead to privilege escalations if not handled properly. Indeed, we must be sure that the source doesn't gain more privileges by being accessible from the destination. This is handled by making sure that the source hierarchy (including the referenced file or directory itself) restricts at least as much the destination hierarchy. If it is not the case, an EXDEV error is returned, making it potentially possible for user space to copy the file hierarchy instead of moving or linking it. Instead of creating different access rights for the source and the destination, we choose to make it simple and consistent for users. Indeed, considering the previous constraint, it would be weird to require such destination access right to be also granted to the source (to make it a superset). Moreover, RENAME_EXCHANGE would also add to the confusion because of paths being both a source and a destination. See the provided documentation for additional details. New tests are provided with a following commit. Reviewed-by: Paul Moore Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20220506161102.525323-8-mic@digikod.net

landlock: Fix same-layer rule unions

2022-05-23T11:27:57Z

The original behavior was to check if the full set of requested accesses was allowed by at least a rule of every relevant layer. This didn't take into account requests for multiple accesses and same-layer rules allowing the union of these accesses in a complementary way. As a result, multiple accesses requested on a file hierarchy matching rules that, together, allowed these accesses, but without a unique rule allowing all of them, was illegitimately denied. This case should be rare in practice and it can only be triggered by the path_rename or file_open hook implementations. For instance, if, for the same layer, a rule allows execution beneath /a/b and another rule allows read beneath /a, requesting access to read and execute at the same time for /a/b should be allowed for this layer. This was an inconsistency because the union of same-layer rule accesses was already allowed if requested once at a time anyway. This fix changes the way allowed accesses are gathered over a path walk. To take into account all these rule accesses, we store in a matrix all layer granting the set of requested accesses, according to the handled accesses. To avoid heap allocation, we use an array on the stack which is 2*13 bytes. A following commit bringing the LANDLOCK_ACCESS_FS_REFER access right will increase this size to reach 112 bytes (2*14*4) in case of link or rename actions. Add a new layout1.layer_rule_unions test to check that accesses from different rules pertaining to the same layer are ORed in a file hierarchy. Also test that it is not the case for rules from different layers. Reviewed-by: Paul Moore Link: https://lore.kernel.org/r/20220506161102.525323-5-mic@digikod.net Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün