blackbird-op-linux/security/safesetid, branch master

security/safesetid: Replace rcu_swap_protected() with rcu_replace_pointer()

2019-10-30T15:45:57+00:00

This commit replaces the use of rcu_swap_protected() with the more intuitively appealing rcu_replace_pointer() as a step towards removing rcu_swap_protected(). Link: https://lore.kernel.org/lkml/CAHk-=wiAsJLw1egFEE=Z7-GGtM6wcvtyytXZA1+BHqta4gg6Hw@mail.gmail.com/ Reported-by: Linus Torvalds Reported-by: Reported-by: kbuild test robot [ paulmck: From rcu_replace() to rcu_replace_pointer() per Ingo Molnar. ] Signed-off-by: Paul E. McKenney Cc: Micah Morton Cc: James Morris Cc: "Serge E. Hallyn" Cc:

LSM: SafeSetID: Stop releasing uninitialized ruleset

2019-09-17T18:27:05+00:00

The first time a rule set is configured for SafeSetID, we shouldn't be trying to release the previously configured ruleset, since there isn't one. Currently, the pointer that would point to a previously configured ruleset is uninitialized on first rule set configuration, leading to a crash when we try to call release_ruleset with that pointer. Acked-by: Jann Horn Signed-off-by: Micah Morton

LSM: SafeSetID: fix use of literal -1 in capable hook

2019-07-15T15:08:03+00:00

The capable() hook returns an error number. -EPERM is actually the same as -1, so this doesn't make a difference in behavior. Signed-off-by: Jann Horn Signed-off-by: Micah Morton

LSM: SafeSetID: verify transitive constrainedness

2019-07-15T15:07:51+00:00

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 Signed-off-by: Micah Morton

LSM: SafeSetID: add read handler

2019-07-15T15:07:40+00:00

For debugging a running system, it is very helpful to be able to see what policy the system is using. Add a read handler that can dump out a copy of the loaded policy. Signed-off-by: Jann Horn Signed-off-by: Micah Morton

LSM: SafeSetID: rewrite userspace API to atomic updates

2019-07-15T15:07:29+00:00

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 Signed-off-by: Micah Morton

LSM: SafeSetID: fix userns handling in securityfs

2019-07-15T15:07:19+00:00

Looking at current_cred() in write handlers is bad form, stop doing that. Also, let's just require that the write is coming from the initial user namespace. Especially SAFESETID_WHITELIST_FLUSH requires privilege over all namespaces, and SAFESETID_WHITELIST_ADD should probably require it as well. Signed-off-by: Jann Horn Signed-off-by: Micah Morton

LSM: SafeSetID: refactor policy parsing

2019-07-15T15:07:09+00:00

In preparation for changing the policy parsing logic, refactor the line parsing logic to be less verbose and move it into a separate function. Signed-off-by: Jann Horn Signed-off-by: Micah Morton

LSM: SafeSetID: refactor safesetid_security_capable()

2019-07-15T15:06:58+00:00

At the moment, safesetid_security_capable() has two nested conditional blocks, and one big comment for all the logic. Chop it up and reduce the amount of indentation. Signed-off-by: Jann Horn Signed-off-by: Micah Morton

LSM: SafeSetID: refactor policy hash table

2019-07-15T15:05:48+00:00

parent_kuid and child_kuid are kuids, there is no reason to make them uint64_t. (And anyway, in the kernel, the normal name for that would be u64, not uint64_t.) check_setuid_policy_hashtable_key() and check_setuid_policy_hashtable_key_value() are basically the same thing, merge them. Also fix the comment that claimed that (1<<8)==128. Signed-off-by: Jann Horn Signed-off-by: Micah Morton