summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/safesetid
AgeCommit message (Collapse)Author
2020-03-25.gitignore: add SPDX License IdentifierMasahiro Yamada
Add SPDX License Identifier to all .gitignore files. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-09selftests: safesetid: Fix Makefile to set correct test programMasami Hiramatsu
Fix Makefile to set safesetid-test.sh to TEST_PROGS instead of non existing run_tests.sh. Without this fix, I got following error. ---- TAP version 13 1..1 # selftests: safesetid: run_tests.sh # Warning: file run_tests.sh is missing! not ok 1 selftests: safesetid: run_tests.sh ---- Fixes: c67e8ec03f3f ("LSM: SafeSetID: add selftest") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-12-09selftests: safesetid: Check the return value of setuid/setgidMasami Hiramatsu
Check the return value of setuid() and setgid(). This fixes the following warnings and improves test result. safesetid-test.c: In function ‘main’: safesetid-test.c:294:2: warning: ignoring return value of ‘setuid’, declared with attribute warn_unused_result [-Wunused-result] setuid(NO_POLICY_USER); ^~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c:295:2: warning: ignoring return value of ‘setgid’, declared with attribute warn_unused_result [-Wunused-result] setgid(NO_POLICY_USER); ^~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c:309:2: warning: ignoring return value of ‘setuid’, declared with attribute warn_unused_result [-Wunused-result] setuid(RESTRICTED_PARENT); ^~~~~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c:310:2: warning: ignoring return value of ‘setgid’, declared with attribute warn_unused_result [-Wunused-result] setgid(RESTRICTED_PARENT); ^~~~~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c: In function ‘test_setuid’: safesetid-test.c:216:3: warning: ignoring return value of ‘setuid’, declared with attribute warn_unused_result [-Wunused-result] setuid(child_uid); ^~~~~~~~~~~~~~~~~ Fixes: c67e8ec03f3f ("LSM: SafeSetID: add selftest") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-12-09selftests: safesetid: Move link library to LDLIBSMasami Hiramatsu
Move -lcap to LDLIBS from CFLAGS because it is a library to be linked. Without this, safesetid failed to build with link error as below. ---- /usr/bin/ld: /tmp/ccL8rZHT.o: in function `drop_caps': safesetid-test.c:(.text+0xe7): undefined reference to `cap_get_proc' /usr/bin/ld: safesetid-test.c:(.text+0x107): undefined reference to `cap_set_flag' /usr/bin/ld: safesetid-test.c:(.text+0x10f): undefined reference to `cap_set_proc' /usr/bin/ld: safesetid-test.c:(.text+0x117): undefined reference to `cap_free' /usr/bin/ld: safesetid-test.c:(.text+0x136): undefined reference to `cap_clear' collect2: error: ld returned 1 exit status ---- Fixes: c67e8ec03f3f ("LSM: SafeSetID: add selftest") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-07-15LSM: SafeSetID: verify transitive constrainednessJann Horn
Someone might write a ruleset like the following, expecting that it securely constrains UID 1 to UIDs 1, 2 and 3: 1:2 1:3 However, because no constraints are applied to UIDs 2 and 3, an attacker with UID 1 can simply first switch to UID 2, then switch to any UID from there. The secure way to write this ruleset would be: 1:2 1:3 2:2 3:3 , which uses "transition to self" as a way to inhibit the default-allow policy without allowing anything specific. This is somewhat unintuitive. To make sure that policy authors don't accidentally write insecure policies because of this, let the kernel verify that a new ruleset does not contain any entries that are constrained, but transitively unconstrained. Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-07-15LSM: SafeSetID: rewrite userspace API to atomic updatesJann Horn
The current API of the SafeSetID LSM uses one write() per rule, and applies each written rule instantly. This has several downsides: - While a policy is being loaded, once a single parent-child pair has been loaded, the parent is restricted to that specific child, even if subsequent rules would allow transitions to other child UIDs. This means that during policy loading, set*uid() can randomly fail. - To replace the policy without rebooting, it is necessary to first flush all old rules. This creates a time window in which no constraints are placed on the use of CAP_SETUID. - If we want to perform sanity checks on the final policy, this requires that the policy isn't constructed in a piecemeal fashion without telling the kernel when it's done. Other kernel APIs - including things like the userns code and netfilter - avoid this problem by performing updates atomically. Luckily, SafeSetID hasn't landed in a stable (upstream) release yet, so maybe it's not too late to completely change the API. The new API for SafeSetID is: If you want to change the policy, open "safesetid/whitelist_policy" and write the entire policy, newline-delimited, in there. Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-02-12LSM: SafeSetID: add selftestMicah Morton
This patch adds a selftest for the SafeSetID LSM. The test requires mounting securityfs if it isn't mounted, creating test users in /etc/passwd, and configuring policies for the SafeSetID LSM through writes to securityfs. Signed-off-by: Micah Morton <mortonm@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>