Commit Graph

9 Commits

Author SHA1 Message Date
Micah Morton 64b634830c LSM: SafeSetID: add setgroups() testing to selftest
Selftest already has support for testing UID and GID transitions.

Signed-off-by: Micah Morton <mortonm@chromium.org>
2022-07-15 18:24:42 +00:00
Micah Morton a1732d6898 LSM: SafeSetID: add GID testing to selftest
GID security policies were added back in v5.10, update the selftest to
reflect this.

Signed-off-by: Micah Morton <mortonm@chromium.org>
2022-07-15 17:35:34 +00:00
Micah Morton b2927170d4 LSM: SafeSetID: selftest cleanup and prepare for GIDs
Add some notes on how to run the test, update the policy file paths to
reflect recent upstream changes, prepare test for adding GID testing.

Signed-off-by: Micah Morton <mortonm@chromium.org>
2022-07-15 17:35:34 +00:00
Micah Morton 92c005a117 LSM: SafeSetID: fix userns bug in selftest
Not sure how this bug got in here but its been there since the original
merge. I think I tested the code on a system that wouldn't let me
clone() with CLONE_NEWUSER flag set so had to comment out these
test_userns invocations.

Trying to map UID 0 inside the userns to UID 0 outside will never work,
even with CAP_SETUID. The code is supposed to test whether we can map
UID 0 in the userns to the UID of the parent process (the one with
CAP_SETUID that is writing the /proc/[pid]/uid_map file).

Signed-off-by: Micah Morton <mortonm@chromium.org>
2022-07-15 17:35:34 +00:00
Colin Ian King 7ce05074b9 selftests: safesetid: Fix spelling mistake "cant" -> "can't"
There is a spelling mistake in an error message. Fix it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-08-26 15:15:24 -06:00
Masami Hiramatsu 295c4e21cf selftests: safesetid: Check the return value of setuid/setgid
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: c67e8ec03f ("LSM: SafeSetID: add selftest")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-12-09 10:53:04 -07:00
Jann Horn 4f72123da5 LSM: SafeSetID: verify transitive constrainedness
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-15 08:07:51 -07:00
Jann Horn 03638e62f5 LSM: SafeSetID: rewrite userspace API to atomic updates
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-07-15 08:07:29 -07:00
Micah Morton c67e8ec03f LSM: SafeSetID: add selftest
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>
2019-02-12 10:58:51 -08:00