2019-01-16 23:46:06 +08: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.
|
|
|
|
*
|
|
|
|
*/
|
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-11 00:56:05 +08:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) "SafeSetID: " fmt
|
|
|
|
|
2019-01-16 23:46:06 +08:00
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/cred.h>
|
|
|
|
|
|
|
|
#include "lsm.h"
|
|
|
|
|
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-11 00:56:05 +08:00
|
|
|
static DEFINE_SPINLOCK(policy_update_lock);
|
2019-01-16 23:46:06 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In the case the input buffer contains one or more invalid UIDs, the kuid_t
|
2019-04-11 00:55:48 +08:00
|
|
|
* variables pointed to by @parent and @child will get updated but this
|
2019-01-16 23:46:06 +08:00
|
|
|
* function will return an error.
|
2019-04-11 00:55:48 +08:00
|
|
|
* Contents of @buf may be modified.
|
2019-01-16 23:46:06 +08: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-11 00:56:05 +08:00
|
|
|
static int parse_policy_line(struct file *file, char *buf,
|
|
|
|
struct setuid_rule *rule)
|
2019-01-16 23:46:06 +08:00
|
|
|
{
|
2019-04-11 00:55:48 +08:00
|
|
|
char *child_str;
|
2019-01-16 23:46:06 +08:00
|
|
|
int ret;
|
2019-04-11 00:55:48 +08:00
|
|
|
u32 parsed_parent, parsed_child;
|
2019-01-16 23:46:06 +08:00
|
|
|
|
2019-04-11 00:55:48 +08:00
|
|
|
/* Format of |buf| string should be <UID>:<UID>. */
|
|
|
|
child_str = strchr(buf, ':');
|
|
|
|
if (child_str == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
*child_str = '\0';
|
|
|
|
child_str++;
|
2019-01-16 23:46:06 +08:00
|
|
|
|
2019-04-11 00:55:48 +08:00
|
|
|
ret = kstrtou32(buf, 0, &parsed_parent);
|
2019-01-16 23:46:06 +08:00
|
|
|
if (ret)
|
2019-04-11 00:55:48 +08:00
|
|
|
return ret;
|
2019-01-16 23:46:06 +08:00
|
|
|
|
2019-04-11 00:55:48 +08:00
|
|
|
ret = kstrtou32(child_str, 0, &parsed_child);
|
2019-01-16 23:46:06 +08:00
|
|
|
if (ret)
|
2019-04-11 00:55:48 +08:00
|
|
|
return ret;
|
2019-01-16 23:46:06 +08: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-11 00:56:05 +08:00
|
|
|
rule->src_uid = make_kuid(file->f_cred->user_ns, parsed_parent);
|
|
|
|
rule->dst_uid = make_kuid(file->f_cred->user_ns, parsed_child);
|
|
|
|
if (!uid_valid(rule->src_uid) || !uid_valid(rule->dst_uid))
|
2019-04-11 00:55:48 +08:00
|
|
|
return -EINVAL;
|
2019-01-16 23:46:06 +08:00
|
|
|
|
2019-04-11 00:55:48 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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-11 00:56:05 +08:00
|
|
|
static void __release_ruleset(struct rcu_head *rcu)
|
2019-04-11 00:55:48 +08: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-11 00:56:05 +08:00
|
|
|
struct setuid_ruleset *pol =
|
|
|
|
container_of(rcu, struct setuid_ruleset, rcu);
|
|
|
|
int bucket;
|
|
|
|
struct setuid_rule *rule;
|
|
|
|
struct hlist_node *tmp;
|
|
|
|
|
|
|
|
hash_for_each_safe(pol->rules, bucket, tmp, rule, next)
|
|
|
|
kfree(rule);
|
|
|
|
kfree(pol);
|
|
|
|
}
|
2019-04-11 00:55:48 +08: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-11 00:56:05 +08:00
|
|
|
static void release_ruleset(struct setuid_ruleset *pol)
|
|
|
|
{
|
|
|
|
call_rcu(&pol->rcu, __release_ruleset);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t handle_policy_update(struct file *file,
|
|
|
|
const char __user *ubuf, size_t len)
|
|
|
|
{
|
|
|
|
struct setuid_ruleset *pol;
|
|
|
|
char *buf, *p, *end;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
pol = kmalloc(sizeof(struct setuid_ruleset), GFP_KERNEL);
|
|
|
|
if (!pol)
|
|
|
|
return -ENOMEM;
|
|
|
|
hash_init(pol->rules);
|
|
|
|
|
|
|
|
p = buf = memdup_user_nul(ubuf, len);
|
|
|
|
if (IS_ERR(buf)) {
|
|
|
|
err = PTR_ERR(buf);
|
|
|
|
goto out_free_pol;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* policy lines, including the last one, end with \n */
|
|
|
|
while (*p != '\0') {
|
|
|
|
struct setuid_rule *rule;
|
|
|
|
|
|
|
|
end = strchr(p, '\n');
|
|
|
|
if (end == NULL) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out_free_buf;
|
|
|
|
}
|
|
|
|
*end = '\0';
|
|
|
|
|
|
|
|
rule = kmalloc(sizeof(struct setuid_rule), GFP_KERNEL);
|
|
|
|
if (!rule) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out_free_buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = parse_policy_line(file, p, rule);
|
|
|
|
if (err)
|
|
|
|
goto out_free_rule;
|
|
|
|
|
|
|
|
if (_setuid_policy_lookup(pol, rule->src_uid, rule->dst_uid) ==
|
|
|
|
SIDPOL_ALLOWED) {
|
|
|
|
pr_warn("bad policy: duplicate entry\n");
|
|
|
|
err = -EEXIST;
|
|
|
|
goto out_free_rule;
|
|
|
|
}
|
|
|
|
|
|
|
|
hash_add(pol->rules, &rule->next, __kuid_val(rule->src_uid));
|
|
|
|
p = end + 1;
|
|
|
|
continue;
|
|
|
|
|
|
|
|
out_free_rule:
|
|
|
|
kfree(rule);
|
|
|
|
goto out_free_buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Everything looks good, apply the policy and release the old one.
|
|
|
|
* What we really want here is an xchg() wrapper for RCU, but since that
|
|
|
|
* doesn't currently exist, just use a spinlock for now.
|
|
|
|
*/
|
|
|
|
spin_lock(&policy_update_lock);
|
|
|
|
rcu_swap_protected(safesetid_setuid_rules, pol,
|
|
|
|
lockdep_is_held(&policy_update_lock));
|
|
|
|
spin_unlock(&policy_update_lock);
|
|
|
|
err = len;
|
|
|
|
|
|
|
|
out_free_buf:
|
|
|
|
kfree(buf);
|
|
|
|
out_free_pol:
|
|
|
|
release_ruleset(pol);
|
|
|
|
return err;
|
2019-01-16 23:46:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t safesetid_file_write(struct file *file,
|
|
|
|
const char __user *buf,
|
|
|
|
size_t len,
|
|
|
|
loff_t *ppos)
|
|
|
|
{
|
2019-04-11 00:55:58 +08:00
|
|
|
if (!file_ns_capable(file, &init_user_ns, CAP_MAC_ADMIN))
|
2019-01-16 23:46:06 +08:00
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
if (*ppos != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
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-11 00:56:05 +08:00
|
|
|
return handle_policy_update(file, buf, len);
|
2019-01-16 23:46:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations safesetid_file_fops = {
|
|
|
|
.write = safesetid_file_write,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init safesetid_init_securityfs(void)
|
|
|
|
{
|
|
|
|
int ret;
|
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-11 00:56:05 +08:00
|
|
|
struct dentry *policy_dir;
|
|
|
|
struct dentry *policy_file;
|
2019-01-16 23:46:06 +08:00
|
|
|
|
|
|
|
if (!safesetid_initialized)
|
|
|
|
return 0;
|
|
|
|
|
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-11 00:56:05 +08:00
|
|
|
policy_dir = securityfs_create_dir("safesetid", NULL);
|
|
|
|
if (IS_ERR(policy_dir)) {
|
|
|
|
ret = PTR_ERR(policy_dir);
|
2019-01-16 23:46:06 +08:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
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-11 00:56:05 +08:00
|
|
|
policy_file = securityfs_create_file("whitelist_policy", 0200,
|
|
|
|
policy_dir, NULL, &safesetid_file_fops);
|
|
|
|
if (IS_ERR(policy_file)) {
|
|
|
|
ret = PTR_ERR(policy_file);
|
|
|
|
goto error;
|
2019-01-16 23:46:06 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
error:
|
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-11 00:56:05 +08:00
|
|
|
securityfs_remove(policy_dir);
|
2019-01-16 23:46:06 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
fs_initcall(safesetid_init_securityfs);
|