2019-01-16 15:46:06 +00: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.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#ifndef _SAFESETID_H
|
|
|
|
#define _SAFESETID_H
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
2019-04-10 16:55:34 +00:00
|
|
|
#include <linux/uidgid.h>
|
|
|
|
#include <linux/hashtable.h>
|
2019-01-16 15:46:06 +00:00
|
|
|
|
|
|
|
/* Flag indicating whether initialization completed */
|
|
|
|
extern int safesetid_initialized;
|
|
|
|
|
2019-04-10 16:55:34 +00:00
|
|
|
enum sid_policy_type {
|
|
|
|
SIDPOL_DEFAULT, /* source ID is unaffected by policy */
|
|
|
|
SIDPOL_CONSTRAINED, /* source ID is affected by policy */
|
|
|
|
SIDPOL_ALLOWED /* target ID explicitly allowed */
|
|
|
|
};
|
|
|
|
|
2020-07-16 19:52:01 +00:00
|
|
|
typedef union {
|
|
|
|
kuid_t uid;
|
|
|
|
kgid_t gid;
|
|
|
|
} kid_t;
|
|
|
|
|
|
|
|
enum setid_type {
|
|
|
|
UID,
|
|
|
|
GID
|
|
|
|
};
|
|
|
|
|
2019-04-10 16:55:34 +00:00
|
|
|
/*
|
2020-07-16 19:52:01 +00:00
|
|
|
* Hash table entry to store safesetid policy signifying that 'src_id'
|
|
|
|
* can set*id to 'dst_id'.
|
2019-04-10 16:55:34 +00:00
|
|
|
*/
|
2020-07-16 19:52:01 +00:00
|
|
|
struct setid_rule {
|
2019-04-10 16:55:34 +00:00
|
|
|
struct hlist_node next;
|
2020-07-16 19:52:01 +00:00
|
|
|
kid_t src_id;
|
|
|
|
kid_t dst_id;
|
|
|
|
|
|
|
|
/* Flag to signal if rule is for UID's or GID's */
|
|
|
|
enum setid_type type;
|
2019-04-10 16:55:34 +00: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 16:56:05 +00:00
|
|
|
#define SETID_HASH_BITS 8 /* 256 buckets in hash table */
|
|
|
|
|
2020-07-16 19:52:01 +00:00
|
|
|
/* Extension of INVALID_UID/INVALID_GID for kid_t type */
|
|
|
|
#define INVALID_ID (kid_t){.uid = INVALID_UID}
|
|
|
|
|
|
|
|
struct setid_ruleset {
|
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 16:56:05 +00:00
|
|
|
DECLARE_HASHTABLE(rules, SETID_HASH_BITS);
|
2019-04-11 20:11:54 +00:00
|
|
|
char *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 16:56:05 +00:00
|
|
|
struct rcu_head rcu;
|
2020-07-16 19:52:01 +00:00
|
|
|
|
|
|
|
//Flag to signal if ruleset is for UID's or GID's
|
|
|
|
enum setid_type type;
|
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 16:56:05 +00:00
|
|
|
};
|
|
|
|
|
2020-07-16 19:52:01 +00:00
|
|
|
enum sid_policy_type _setid_policy_lookup(struct setid_ruleset *policy,
|
|
|
|
kid_t src, kid_t dst);
|
2019-01-16 15:46:06 +00:00
|
|
|
|
2020-07-16 19:52:01 +00:00
|
|
|
extern struct setid_ruleset __rcu *safesetid_setuid_rules;
|
|
|
|
extern struct setid_ruleset __rcu *safesetid_setgid_rules;
|
2019-01-16 15:46:06 +00:00
|
|
|
|
|
|
|
#endif /* _SAFESETID_H */
|