#
b1a867ee |
|
09-Nov-2023 |
Paul Moore <paul@paul-moore.com> |
lsm: mark the lsm_id variables are marked as static As the kernel test robot helpfully reminded us, all of the lsm_id instances defined inside the various LSMs should be marked as static. The one exception is Landlock which uses its lsm_id variable across multiple source files with an extern declaration in a header file. Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
|
#
f3b8788c |
|
12-Sep-2023 |
Casey Schaufler <casey@schaufler-ca.com> |
LSM: Identify modules by more than name Create a struct lsm_id to contain identifying information about Linux Security Modules (LSMs). At inception this contains the name of the module and an identifier associated with the security module. Change the security_add_hooks() interface to use this structure. Change the individual modules to maintain their own struct lsm_id and pass it to security_add_hooks(). The values are for LSM identifiers are defined in a new UAPI header file linux/lsm.h. Each existing LSM has been updated to include it's LSMID in the lsm_id. The LSM ID values are sequential, with the oldest module LSM_ID_CAPABILITY being the lowest value and the existing modules numbered in the order they were included in the main line kernel. This is an arbitrary convention for assigning the values, but none better presents itself. The value 0 is defined as being invalid. The values 1-99 are reserved for any special case uses which may arise in the future. This may include attributes of the LSM infrastructure itself, possibly related to namespacing or network attribute management. A special range is identified for such attributes to help reduce confusion for developers unfamiliar with LSMs. LSM attribute values are defined for the attributes presented by modules that are available today. As with the LSM IDs, The value 0 is defined as being invalid. The values 1-99 are reserved for any special case uses which may arise in the future. Cc: linux-security-module <linux-security-module@vger.kernel.org> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Serge Hallyn <serge@hallyn.com> Reviewed-by: Mickael Salaun <mic@digikod.net> Reviewed-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Kees Cook <keescook@chromium.org> Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> [PM: forward ported beyond v6.6 due merge window changes] Signed-off-by: Paul Moore <paul@paul-moore.com>
|
#
970ebb8a |
|
03-May-2023 |
Alexander Mikhalitsyn <alexander@mihalicyn.com> |
SafeSetID: fix UID printed instead of GID pr_warn message clearly says that GID should be printed, but we have UID there. Let's fix that. Found accidentally during the work on isolated user namespaces. Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> [PM: fix spelling errors in description, subject tweak] Signed-off-by: Paul Moore <paul@paul-moore.com>
|
#
3e3374d3 |
|
08-Jun-2022 |
Micah Morton <mortonm@chromium.org> |
LSM: SafeSetID: Add setgroups() security policy handling The SafeSetID LSM has functionality for restricting setuid()/setgid() syscalls based on its configured security policies. This patch adds the analogous functionality for the setgroups() syscall. Security policy for the setgroups() syscall follows the same policies that are installed on the system for setgid() syscalls. Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
1b8b7192 |
|
08-Jun-2021 |
Austin Kim <austindh.kim@gmail.com> |
LSM: SafeSetID: Mark safesetid_initialized as __initdata Mark safesetid_initialized as __initdata since it is only used in initialization routine. Signed-off-by: Austin Kim <austindh.kim@gmail.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
1ca86ac1 |
|
09-Mar-2021 |
Yanwei Gao <gaoyanwei.tx@gmail.com> |
LSM: SafeSetID: Fix code specification by scripts/checkpatch.pl First, the code is found to be irregular through checkpatch.pl. Then I found break is really useless here. Signed-off-by: Yanwei Gao <gaoyanwei.tx@gmail.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
03ca0ec1 |
|
11-Aug-2020 |
Thomas Cedeno <thomascedeno@google.com> |
LSM: SafeSetID: Fix warnings reported by test bot Fix multiple cast-to-union warnings related to casting kuid_t and kgid_t types to kid_t union type. Also fix incompatible type warning that arises from accidental omission of "__rcu" qualifier on the struct setid_ruleset pointer in the argument list for safesetid_file_read(). Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thomas Cedeno <thomascedeno@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
5294bac9 |
|
16-Jul-2020 |
Thomas Cedeno <thomascedeno@google.com> |
LSM: SafeSetID: Add GID security policy handling The SafeSetID LSM has functionality for restricting setuid() calls based on its configured security policies. This patch adds the analogous functionality for setgid() calls. This is mostly a copy-and-paste change with some code deduplication, plus slight modifications/name changes to the policy-rule-related structs (now contain GID rules in addition to the UID ones) and some type generalization since SafeSetID now needs to deal with kgid_t and kuid_t types. Signed-off-by: Thomas Cedeno <thomascedeno@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
e10337da |
|
10-Apr-2019 |
Jann Horn <jannh@google.com> |
LSM: SafeSetID: fix use of literal -1 in capable hook 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 <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
03638e62 |
|
10-Apr-2019 |
Jann Horn <jannh@google.com> |
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>
|
#
8068866c |
|
10-Apr-2019 |
Jann Horn <jannh@google.com> |
LSM: SafeSetID: refactor safesetid_security_capable() 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 <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
1cd02a27 |
|
10-Apr-2019 |
Jann Horn <jannh@google.com> |
LSM: SafeSetID: refactor policy hash table 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 <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
7ef6b306 |
|
10-Apr-2019 |
Jann Horn <jannh@google.com> |
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>
|
#
c783d525 |
|
10-Apr-2019 |
Jann Horn <jannh@google.com> |
LSM: SafeSetID: fix pr_warn() to include newline Fix the pr_warn() calls in the SafeSetID LSM to have newlines at the end. Without this, denial messages will be buffered as incomplete lines in log_output(), and will then only show up once something else prints into dmesg. Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
|
#
3cf5d076 |
|
23-May-2019 |
Eric W. Biederman <ebiederm@xmission.com> |
signal: Remove task parameter from force_sig All of the remaining callers pass current into force_sig so remove the task parameter to make this obvious and to make misuse more difficult in the future. This also makes it clear force_sig passes current into force_sig_info. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
#
2181e084 |
|
30-Jan-2019 |
Micah Morton <mortonm@chromium.org> |
LSM: SafeSetID: remove unused include The include for asm/syscall.h was needed in a prior version of lsm.c that checked return values of syscall_get_nr, but since we did away with that part of the code this include is no longer necessary. Take out this include since it breaks builds for certain architectures. We no longer have any arch-specific code in SafeSetID. Signed-off-by: Micah Morton <mortonm@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
|
#
f67e20d2 |
|
28-Jan-2019 |
Micah Morton <mortonm@chromium.org> |
LSM: Add 'name' field for SafeSetID in DEFINE_LSM Without this, system boot was crashing with: [0.174285] LSM: Security Framework initializing [0.175277] BUG: unable to handle kernel NULL pointer dereference ... [0.176272] Call Trace: [0.176272] ordered_lsm_parse+0x112/0x20b [0.176272] security_init+0x9b/0x3ab [0.176272] start_kernel+0x413/0x479 [0.176272] secondary_startup_64+0xa4/0xb0 Signed-off-by: Micah Morton <mortonm@chromium.org> Fixed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
|
#
aeca4e2c |
|
16-Jan-2019 |
Micah Morton <mortonm@chromium.org> |
LSM: add SafeSetID module that gates setid calls SafeSetID gates the setid family of syscalls to restrict UID/GID transitions from a given UID/GID to only those approved by a system-wide whitelist. These restrictions also prohibit the given UIDs/GIDs from obtaining auxiliary privileges associated with CAP_SET{U/G}ID, such as allowing a user to set up user namespace UID mappings. For now, only gating the set*uid family of syscalls is supported, with support for set*gid coming in a future patch set. Signed-off-by: Micah Morton <mortonm@chromium.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
|