2019-01-16 16:46:06 +01: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-10 18:56:05 +02:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) "SafeSetID: " fmt
|
|
|
|
|
2019-01-16 16:46:06 +01:00
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/cred.h>
|
|
|
|
|
|
|
|
#include "lsm.h"
|
|
|
|
|
2019-04-11 22:11:54 +02:00
|
|
|
static DEFINE_MUTEX(policy_update_lock);
|
2019-01-16 16:46:06 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In the case the input buffer contains one or more invalid UIDs, the kuid_t
|
2019-04-10 18:55:48 +02:00
|
|
|
* variables pointed to by @parent and @child will get updated but this
|
2019-01-16 16:46:06 +01:00
|
|
|
* function will return an error.
|
2019-04-10 18:55:48 +02:00
|
|
|
* Contents of @buf may be modified.
|
2019-01-16 16:46:06 +01: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 18:56:05 +02:00
|
|
|
static int parse_policy_line(struct file *file, char *buf,
|
|
|
|
struct setuid_rule *rule)
|
2019-01-16 16:46:06 +01:00
|
|
|
{
|
2019-04-10 18:55:48 +02:00
|
|
|
char *child_str;
|
2019-01-16 16:46:06 +01:00
|
|
|
int ret;
|
2019-04-10 18:55:48 +02:00
|
|
|
u32 parsed_parent, parsed_child;
|
2019-01-16 16:46:06 +01:00
|
|
|
|
2019-04-10 18:55:48 +02: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 16:46:06 +01:00
|
|
|
|
2019-04-10 18:55:48 +02:00
|
|
|
ret = kstrtou32(buf, 0, &parsed_parent);
|
2019-01-16 16:46:06 +01:00
|
|
|
if (ret)
|
2019-04-10 18:55:48 +02:00
|
|
|
return ret;
|
2019-01-16 16:46:06 +01:00
|
|
|
|
2019-04-10 18:55:48 +02:00
|
|
|
ret = kstrtou32(child_str, 0, &parsed_child);
|
2019-01-16 16:46:06 +01:00
|
|
|
if (ret)
|
2019-04-10 18:55:48 +02:00
|
|
|
return ret;
|
2019-01-16 16:46:06 +01: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 18:56:05 +02: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-10 18:55:48 +02:00
|
|
|
return -EINVAL;
|
2019-01-16 16:46:06 +01:00
|
|
|
|
2019-04-10 18:55:48 +02: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-10 18:56:05 +02:00
|
|
|
static void __release_ruleset(struct rcu_head *rcu)
|
2019-04-10 18:55:48 +02: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 18:56:05 +02: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);
|
2019-04-11 22:11:54 +02:00
|
|
|
kfree(pol->policy_str);
|
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 18:56:05 +02:00
|
|
|
kfree(pol);
|
|
|
|
}
|
2019-04-10 18:55:48 +02: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 18:56:05 +02:00
|
|
|
static void release_ruleset(struct setuid_ruleset *pol)
|
|
|
|
{
|
|
|
|
call_rcu(&pol->rcu, __release_ruleset);
|
|
|
|
}
|
|
|
|
|
2019-04-11 22:12:43 +02:00
|
|
|
static void insert_rule(struct setuid_ruleset *pol, struct setuid_rule *rule)
|
|
|
|
{
|
|
|
|
hash_add(pol->rules, &rule->next, __kuid_val(rule->src_uid));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int verify_ruleset(struct setuid_ruleset *pol)
|
|
|
|
{
|
|
|
|
int bucket;
|
|
|
|
struct setuid_rule *rule, *nrule;
|
|
|
|
int res = 0;
|
|
|
|
|
|
|
|
hash_for_each(pol->rules, bucket, rule, next) {
|
|
|
|
if (_setuid_policy_lookup(pol, rule->dst_uid, INVALID_UID) ==
|
|
|
|
SIDPOL_DEFAULT) {
|
|
|
|
pr_warn("insecure policy detected: uid %d is constrained but transitively unconstrained through uid %d\n",
|
|
|
|
__kuid_val(rule->src_uid),
|
|
|
|
__kuid_val(rule->dst_uid));
|
|
|
|
res = -EINVAL;
|
|
|
|
|
|
|
|
/* fix it up */
|
|
|
|
nrule = kmalloc(sizeof(struct setuid_rule), GFP_KERNEL);
|
|
|
|
if (!nrule)
|
|
|
|
return -ENOMEM;
|
|
|
|
nrule->src_uid = rule->dst_uid;
|
|
|
|
nrule->dst_uid = rule->dst_uid;
|
|
|
|
insert_rule(pol, nrule);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
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 18:56:05 +02:00
|
|
|
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;
|
2019-04-11 22:11:54 +02:00
|
|
|
pol->policy_str = NULL;
|
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 18:56:05 +02:00
|
|
|
hash_init(pol->rules);
|
|
|
|
|
|
|
|
p = buf = memdup_user_nul(ubuf, len);
|
|
|
|
if (IS_ERR(buf)) {
|
|
|
|
err = PTR_ERR(buf);
|
|
|
|
goto out_free_pol;
|
|
|
|
}
|
2019-04-11 22:11:54 +02:00
|
|
|
pol->policy_str = kstrdup(buf, GFP_KERNEL);
|
|
|
|
if (pol->policy_str == NULL) {
|
|
|
|
err = -ENOMEM;
|
|
|
|
goto out_free_buf;
|
|
|
|
}
|
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 18:56:05 +02:00
|
|
|
|
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
2019-04-11 22:12:43 +02:00
|
|
|
insert_rule(pol, rule);
|
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 18:56:05 +02:00
|
|
|
p = end + 1;
|
|
|
|
continue;
|
|
|
|
|
|
|
|
out_free_rule:
|
|
|
|
kfree(rule);
|
|
|
|
goto out_free_buf;
|
|
|
|
}
|
|
|
|
|
2019-04-11 22:12:43 +02:00
|
|
|
err = verify_ruleset(pol);
|
|
|
|
/* bogus policy falls through after fixing it up */
|
|
|
|
if (err && err != -EINVAL)
|
|
|
|
goto out_free_buf;
|
|
|
|
|
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 18:56:05 +02:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2019-04-11 22:11:54 +02:00
|
|
|
mutex_lock(&policy_update_lock);
|
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 18:56:05 +02:00
|
|
|
rcu_swap_protected(safesetid_setuid_rules, pol,
|
|
|
|
lockdep_is_held(&policy_update_lock));
|
2019-04-11 22:11:54 +02:00
|
|
|
mutex_unlock(&policy_update_lock);
|
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 18:56:05 +02:00
|
|
|
err = len;
|
|
|
|
|
|
|
|
out_free_buf:
|
|
|
|
kfree(buf);
|
|
|
|
out_free_pol:
|
2019-09-17 20:27:05 +02:00
|
|
|
if (pol)
|
|
|
|
release_ruleset(pol);
|
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 18:56:05 +02:00
|
|
|
return err;
|
2019-01-16 16:46:06 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t safesetid_file_write(struct file *file,
|
|
|
|
const char __user *buf,
|
|
|
|
size_t len,
|
|
|
|
loff_t *ppos)
|
|
|
|
{
|
2019-04-10 18:55:58 +02:00
|
|
|
if (!file_ns_capable(file, &init_user_ns, CAP_MAC_ADMIN))
|
2019-01-16 16:46:06 +01: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-10 18:56:05 +02:00
|
|
|
return handle_policy_update(file, buf, len);
|
2019-01-16 16:46:06 +01:00
|
|
|
}
|
|
|
|
|
2019-04-11 22:11:54 +02:00
|
|
|
static ssize_t safesetid_file_read(struct file *file, char __user *buf,
|
|
|
|
size_t len, loff_t *ppos)
|
|
|
|
{
|
|
|
|
ssize_t res = 0;
|
|
|
|
struct setuid_ruleset *pol;
|
|
|
|
const char *kbuf;
|
|
|
|
|
|
|
|
mutex_lock(&policy_update_lock);
|
|
|
|
pol = rcu_dereference_protected(safesetid_setuid_rules,
|
|
|
|
lockdep_is_held(&policy_update_lock));
|
|
|
|
if (pol) {
|
|
|
|
kbuf = pol->policy_str;
|
|
|
|
res = simple_read_from_buffer(buf, len, ppos,
|
|
|
|
kbuf, strlen(kbuf));
|
|
|
|
}
|
|
|
|
mutex_unlock(&policy_update_lock);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2019-01-16 16:46:06 +01:00
|
|
|
static const struct file_operations safesetid_file_fops = {
|
2019-04-11 22:11:54 +02:00
|
|
|
.read = safesetid_file_read,
|
2019-01-16 16:46:06 +01:00
|
|
|
.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-10 18:56:05 +02:00
|
|
|
struct dentry *policy_dir;
|
|
|
|
struct dentry *policy_file;
|
2019-01-16 16:46:06 +01: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-10 18:56:05 +02:00
|
|
|
policy_dir = securityfs_create_dir("safesetid", NULL);
|
|
|
|
if (IS_ERR(policy_dir)) {
|
|
|
|
ret = PTR_ERR(policy_dir);
|
2019-01-16 16:46:06 +01:00
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
|
2019-04-11 22:11:54 +02:00
|
|
|
policy_file = securityfs_create_file("whitelist_policy", 0600,
|
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 18:56:05 +02:00
|
|
|
policy_dir, NULL, &safesetid_file_fops);
|
|
|
|
if (IS_ERR(policy_file)) {
|
|
|
|
ret = PTR_ERR(policy_file);
|
|
|
|
goto error;
|
2019-01-16 16:46:06 +01: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-10 18:56:05 +02:00
|
|
|
securityfs_remove(policy_dir);
|
2019-01-16 16:46:06 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
fs_initcall(safesetid_init_securityfs);
|