2019-01-16 18:46:06 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* SafeSetID Linux Security Module
|
|
|
|
*
|
|
|
|
* Author: Micah Morton <mortonm@chromium.org>
|
|
|
|
*
|
|
|
|
* Copyright (C) 2018 The Chromium OS Authors.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2, as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) "SafeSetID: " fmt
|
|
|
|
|
|
|
|
#include <linux/lsm_hooks.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/ptrace.h>
|
|
|
|
#include <linux/sched/task_stack.h>
|
|
|
|
#include <linux/security.h>
|
2019-04-10 19:55:34 +03:00
|
|
|
#include "lsm.h"
|
2019-01-16 18:46:06 +03:00
|
|
|
|
|
|
|
/* Flag indicating whether initialization completed */
|
|
|
|
int safesetid_initialized;
|
|
|
|
|
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-04-10 19:56:05 +03:00
|
|
|
struct setuid_ruleset __rcu *safesetid_setuid_rules;
|
2019-01-16 18:46:06 +03:00
|
|
|
|
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-04-10 19:56:05 +03:00
|
|
|
/* Compute a decision for a transition from @src to @dst under @policy. */
|
|
|
|
enum sid_policy_type _setuid_policy_lookup(struct setuid_ruleset *policy,
|
|
|
|
kuid_t src, kuid_t dst)
|
2019-01-16 18:46:06 +03:00
|
|
|
{
|
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-04-10 19:56:05 +03:00
|
|
|
struct setuid_rule *rule;
|
2019-04-10 19:55:34 +03:00
|
|
|
enum sid_policy_type result = SIDPOL_DEFAULT;
|
2019-01-16 18:46:06 +03:00
|
|
|
|
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-04-10 19:56:05 +03:00
|
|
|
hash_for_each_possible(policy->rules, rule, next, __kuid_val(src)) {
|
|
|
|
if (!uid_eq(rule->src_uid, src))
|
2019-04-10 19:55:34 +03:00
|
|
|
continue;
|
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-04-10 19:56:05 +03:00
|
|
|
if (uid_eq(rule->dst_uid, dst))
|
2019-04-10 19:55:34 +03:00
|
|
|
return SIDPOL_ALLOWED;
|
|
|
|
result = SIDPOL_CONSTRAINED;
|
2019-01-16 18:46:06 +03:00
|
|
|
}
|
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-04-10 19:56:05 +03:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute a decision for a transition from @src to @dst under the active
|
|
|
|
* policy.
|
|
|
|
*/
|
|
|
|
static enum sid_policy_type setuid_policy_lookup(kuid_t src, kuid_t dst)
|
|
|
|
{
|
|
|
|
enum sid_policy_type result = SIDPOL_DEFAULT;
|
|
|
|
struct setuid_ruleset *pol;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
pol = rcu_dereference(safesetid_setuid_rules);
|
|
|
|
if (pol)
|
|
|
|
result = _setuid_policy_lookup(pol, src, dst);
|
2019-01-16 18:46:06 +03:00
|
|
|
rcu_read_unlock();
|
2019-04-10 19:55:34 +03:00
|
|
|
return result;
|
2019-01-16 18:46:06 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static int safesetid_security_capable(const struct cred *cred,
|
|
|
|
struct user_namespace *ns,
|
|
|
|
int cap,
|
|
|
|
unsigned int opts)
|
|
|
|
{
|
2019-04-10 19:55:41 +03:00
|
|
|
/* We're only interested in CAP_SETUID. */
|
|
|
|
if (cap != CAP_SETUID)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If CAP_SETUID is currently used for a set*uid() syscall, we want to
|
|
|
|
* let it go through here; the real security check happens later, in the
|
|
|
|
* task_fix_setuid hook.
|
|
|
|
*/
|
|
|
|
if ((opts & CAP_OPT_INSETID) != 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If no policy applies to this task, allow the use of CAP_SETUID for
|
|
|
|
* other purposes.
|
|
|
|
*/
|
|
|
|
if (setuid_policy_lookup(cred->uid, INVALID_UID) == SIDPOL_DEFAULT)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reject use of CAP_SETUID for functionality other than calling
|
|
|
|
* set*uid() (e.g. setting up userns uid mappings).
|
|
|
|
*/
|
|
|
|
pr_warn("Operation requires CAP_SETUID, which is not available to UID %u for operations besides approved set*uid transitions\n",
|
|
|
|
__kuid_val(cred->uid));
|
2019-04-10 19:56:27 +03:00
|
|
|
return -EPERM;
|
2019-01-16 18:46:06 +03:00
|
|
|
}
|
|
|
|
|
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
|
|
|
/*
|
|
|
|
* Check whether a caller with old credentials @old is allowed to switch to
|
|
|
|
* credentials that contain @new_uid.
|
|
|
|
*/
|
|
|
|
static bool uid_permitted_for_cred(const struct cred *old, kuid_t new_uid)
|
2019-01-16 18:46:06 +03:00
|
|
|
{
|
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
|
|
|
bool permitted;
|
|
|
|
|
|
|
|
/* If our old creds already had this UID in it, it's fine. */
|
|
|
|
if (uid_eq(new_uid, old->uid) || uid_eq(new_uid, old->euid) ||
|
|
|
|
uid_eq(new_uid, old->suid))
|
|
|
|
return true;
|
|
|
|
|
2019-01-16 18:46:06 +03:00
|
|
|
/*
|
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
|
|
|
* Transitions to new UIDs require a check against the policy of the old
|
|
|
|
* RUID.
|
2019-01-16 18:46:06 +03:00
|
|
|
*/
|
2019-04-10 19:55:34 +03:00
|
|
|
permitted =
|
|
|
|
setuid_policy_lookup(old->uid, new_uid) != SIDPOL_CONSTRAINED;
|
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
|
|
|
if (!permitted) {
|
|
|
|
pr_warn("UID transition ((%d,%d,%d) -> %d) blocked\n",
|
|
|
|
__kuid_val(old->uid), __kuid_val(old->euid),
|
|
|
|
__kuid_val(old->suid), __kuid_val(new_uid));
|
|
|
|
}
|
|
|
|
return permitted;
|
2019-01-16 18:46:06 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether there is either an exception for user under old cred struct to
|
|
|
|
* set*uid to user under new cred struct, or the UID transition is allowed (by
|
|
|
|
* Linux set*uid rules) even without CAP_SETUID.
|
|
|
|
*/
|
|
|
|
static int safesetid_task_fix_setuid(struct cred *new,
|
|
|
|
const struct cred *old,
|
|
|
|
int flags)
|
|
|
|
{
|
|
|
|
|
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
|
|
|
/* Do nothing if there are no setuid restrictions for our old RUID. */
|
2019-04-10 19:55:34 +03:00
|
|
|
if (setuid_policy_lookup(old->uid, INVALID_UID) == SIDPOL_DEFAULT)
|
2019-01-16 18:46:06 +03:00
|
|
|
return 0;
|
|
|
|
|
LSM: SafeSetID: fix check for setresuid(new1, new2, new3)
With the old code, when a process with the (real,effective,saved) UID set
(1,1,1) calls setresuid(2,3,4), safesetid_task_fix_setuid() only checks
whether the transition 1->2 is permitted; the transitions 1->3 and 1->4 are
not checked. Fix this.
This is also a good opportunity to refactor safesetid_task_fix_setuid() to
be less verbose - having one branch per set*uid() syscall is unnecessary.
Note that this slightly changes semantics: The UID transition check for
UIDs that were not in the old cred struct is now always performed against
the policy of the RUID. I think that's more consistent anyway, since the
RUID is also the one that decides whether any policy is enforced at all.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Micah Morton <mortonm@chromium.org>
2019-04-10 19:55:19 +03:00
|
|
|
if (uid_permitted_for_cred(old, new->uid) &&
|
|
|
|
uid_permitted_for_cred(old, new->euid) &&
|
|
|
|
uid_permitted_for_cred(old, new->suid) &&
|
|
|
|
uid_permitted_for_cred(old, new->fsuid))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Kill this process to avoid potential security vulnerabilities
|
|
|
|
* that could arise from a missing whitelist entry preventing a
|
|
|
|
* privileged process from dropping to a lesser-privileged one.
|
|
|
|
*/
|
|
|
|
force_sig(SIGKILL);
|
|
|
|
return -EACCES;
|
2019-01-16 18:46:06 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct security_hook_list safesetid_security_hooks[] = {
|
|
|
|
LSM_HOOK_INIT(task_fix_setuid, safesetid_task_fix_setuid),
|
|
|
|
LSM_HOOK_INIT(capable, safesetid_security_capable)
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init safesetid_security_init(void)
|
|
|
|
{
|
|
|
|
security_add_hooks(safesetid_security_hooks,
|
|
|
|
ARRAY_SIZE(safesetid_security_hooks), "safesetid");
|
|
|
|
|
|
|
|
/* Report that SafeSetID successfully initialized */
|
|
|
|
safesetid_initialized = 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_LSM(safesetid_security_init) = {
|
|
|
|
.init = safesetid_security_init,
|
2019-01-28 23:30:56 +03:00
|
|
|
.name = "safesetid",
|
2019-01-16 18:46:06 +03:00
|
|
|
};
|