summaryrefslogtreecommitdiffstats
path: root/security
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | LSM: Add 'name' field for SafeSetID in DEFINE_LSMMicah Morton2019-01-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | LSM: add SafeSetID module that gates setid callsMicah Morton2019-01-257-1/+526
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | tomoyo: Allow multiple use_group lines.Tetsuo Handa2019-01-243-22/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Being able to specify multiple "use_group" lines makes it easier to write whitelisted policies. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | tomoyo: Coding style fix.Tetsuo Handa2019-01-2415-105/+309
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow many of recommendations by scripts/checkpatch.pl, and follow "lift switch variables out of switches" by Kees Cook. This patch makes no functional change. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | tomoyo: Swicth from cred->security to task_struct->security.Tetsuo Handa2019-01-235-122/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TOMOYO security module is designed to use "struct task_struct"->security in order to allow per "struct task_struct" tracking without being disturbed by unable to update "struct cred"->security due to override mechanism. Now that infrastructure-managed security blob is ready, this patch updates TOMOYO to use "struct task_struct"->security. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | security: keys: annotate implicit fall throughsMathieu Malaterre2019-01-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warnings: security/keys/request_key.c:293:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/request_key.c:298:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/request_key.c:307:7: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | security: keys: annotate implicit fall throughsMathieu Malaterre2019-01-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a plan to build the kernel with -Wimplicit-fallthrough and these places in the code produced warnings (W=1). Fix them up. This commit remove the following warning: security/keys/process_keys.c:380:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/process_keys.c:404:7: warning: this statement may fall through [-Wimplicit-fallthrough=] security/keys/process_keys.c:424:7: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | security: keys: annotate implicit fall throughMathieu Malaterre2019-01-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a plan to build the kernel with -Wimplicit-fallthrough and this place in the code produced a warning (W=1). This commit remove the following warning: security/keys/keyring.c:248:10: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | apparmor: Adjust offset when accessing task blob.Tetsuo Handa2019-01-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AppArmor will no longer be the only user of task blob after TOMOYO started using task blob. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: f4ad8f2c4076 ("LSM: Infrastructure management of the task security") Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | Merge tag 'v5.0-rc3' into next-generalJames Morris2019-01-223-2/+12
| |\ \ \ | | | | | | | | | | | | | | | | | | | | Sync to Linux 5.0-rc3 to pull in the VFS changes which impacted a lot of the LSM code.
| * | | | LSM: Make some functions staticWei Yongjun2019-01-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following sparse warnings: security/security.c:533:5: warning: symbol 'lsm_task_alloc' was not declared. Should it be static? security/security.c:554:5: warning: symbol 'lsm_ipc_alloc' was not declared. Should it be static? security/security.c:575:5: warning: symbol 'lsm_msg_msg_alloc' was not declared. Should it be static? Fixes: f4ad8f2c4076 ("LSM: Infrastructure management of the task security") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | | LSM: Make lsm_early_cred() and lsm_early_task() local functions.Tetsuo Handa2019-01-185-22/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since current->cred == current->real_cred when ordered_lsm_init() is called, and lsm_early_cred()/lsm_early_task() need to be called between the amount of required bytes is determined and module specific initialization function is called, we can move these calls from individual modules to ordered_lsm_init(). Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | | LSM: generalize flag passing to security_capableMicah Morton2019-01-109-39/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides a general mechanism for passing flags to the security_capable LSM hook. It replaces the specific 'audit' flag that is used to tell security_capable whether it should log an audit message for the given capability check. The reason for generalizing this flag passing is so we can add an additional flag that signifies whether security_capable is being called by a setid syscall (which is needed by the proposed SafeSetID LSM). Signed-off-by: Micah Morton <mortonm@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | | | TOMOYO: Update LSM flags to no longer be exclusiveKees Cook2019-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With blob sharing in place, TOMOYO is no longer an exclusive LSM, so it can operate separately now. Mark it as such. Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Infrastructure management of the ipc security blobCasey Schaufler2019-01-085-121/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move management of the kern_ipc_perm->security and msg_msg->security blobs out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | Smack: Abstract use of ipc security blobsCasey Schaufler2019-01-082-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the ipc->security pointer directly. Don't use the msg_msg->security pointer directly. Provide helper functions that provides the security blob pointers. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | SELinux: Abstract use of ipc security blobsCasey Schaufler2019-01-082-9/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the ipc->security pointer directly. Don't use the msg_msg->security pointer directly. Provide helper functions that provides the security blob pointers. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Infrastructure management of the task securityCasey Schaufler2019-01-083-27/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move management of the task_struct->security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. The only user of this blob is AppArmor. The AppArmor use is abstracted to avoid future conflict. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Infrastructure management of the inode securityCasey Schaufler2019-01-085-98/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move management of the inode->i_security blob out of the individual security modules and into the security infrastructure. Instead of allocating the blobs from within the modules the modules tell the infrastructure how much space is required, and the space is allocated there. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | Smack: Abstract use of inode security blobCasey Schaufler2019-01-082-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the inode->i_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | SELinux: Abstract use of inode security blobCasey Schaufler2019-01-083-15/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the inode->i_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Infrastructure management of the file securityCasey Schaufler2019-01-087-51/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move management of the file->f_security blob out of the individual security modules and into the infrastructure. The modules no longer allocate or free the data, instead they tell the infrastructure how much space they require. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | Smack: Abstract use of file security blobCasey Schaufler2019-01-082-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the file->f_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | SELinux: Abstract use of file security blobCasey Schaufler2019-01-082-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the file->f_security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | Infrastructure management of the cred security blobCasey Schaufler2019-01-0810-102/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move management of the cred security blob out of the security modules and into the security infrastructre. Instead of allocating and freeing space the security modules tell the infrastructure how much space they require. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | TOMOYO: Abstract use of cred security blobCasey Schaufler2019-01-084-16/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the cred->security pointer directly. Provide helper functions that provide the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | AppArmor: Abstract use of cred security blobCasey Schaufler2019-01-084-10/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the cred->security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | SELinux: Remove unused selinux_is_enabledCasey Schaufler2019-01-085-29/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are no longer users of selinux_is_enabled(). Remove it. As selinux_is_enabled() is the only reason for include/linux/selinux.h remove that as well. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | SELinux: Remove cred security blob poisoningCasey Schaufler2019-01-081-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The SELinux specific credential poisioning only makes sense if SELinux is managing the credentials. As the intent of this patch set is to move the blob management out of the modules and into the infrastructure, the SELinux specific code has to go. The poisioning could be introduced into the infrastructure at some later date. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | SELinux: Abstract use of cred security blobCasey Schaufler2019-01-083-29/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the cred->security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | Smack: Abstract use of cred security blobCasey Schaufler2019-01-084-43/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use the cred->security pointer directly. Provide a helper function that provides the security blob pointer. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> [kees: adjusted for ordered init series] Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | procfs: add smack subdir to attrsCasey Schaufler2019-01-081-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in 2007 I made what turned out to be a rather serious mistake in the implementation of the Smack security module. The SELinux module used an interface in /proc to manipulate the security context on processes. Rather than use a similar interface, I used the same interface. The AppArmor team did likewise. Now /proc/.../attr/current will tell you the security "context" of the process, but it will be different depending on the security module you're using. This patch provides a subdirectory in /proc/.../attr for Smack. Smack user space can use the "current" file in this subdirectory and never have to worry about getting SELinux attributes by mistake. Programs that use the old interface will continue to work (or fail, as the case may be) as before. The proposed S.A.R.A security module is dependent on the mechanism to create its own attr subdirectory. The original implementation is by Kees Cook. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | capability: Initialize as LSM_ORDER_FIRSTKees Cook2019-01-082-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts capabilities to use the new LSM_ORDER_FIRST position. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | LSM: Introduce enum lsm_orderKees Cook2019-01-081-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for distinguishing the "capability" LSM from other LSMs, it must be ordered first. This introduces LSM_ORDER_MUTABLE for the general LSMs and LSM_ORDER_FIRST for capability. In the future LSM_ORDER_LAST for could be added for anything that must run last (e.g. Landlock may use this). Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | Yama: Initialize as ordered LSMKees Cook2019-01-083-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts Yama from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | LoadPin: Initialize as ordered LSMKees Cook2019-01-083-40/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This converts LoadPin from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | LSM: Split LSM preparation from initializationKees Cook2019-01-081-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we already have to do a pass through the LSMs to figure out if exclusive LSMs should be disabled after the first one is seen as enabled, this splits the logic up a bit more cleanly. Now we do a full "prepare" pass through the LSMs (which also allows for later use by the blob-sharing code), before starting the LSM initialization pass. Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Add all exclusive LSMs to ordered initializationCasey Schaufler2019-01-081-25/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes CONFIG_DEFAULT_SECURITY in favor of the explicit ordering offered by CONFIG_LSM and adds all the exclusive LSMs to the ordered LSM initialization. The old meaning of CONFIG_DEFAULT_SECURITY is now captured by which exclusive LSM is listed first in the LSM order. All LSMs not added to the ordered list are explicitly disabled. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUEKees Cook2019-01-082-19/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for removing CONFIG_DEFAULT_SECURITY, this removes the soon-to-be redundant SECURITY_SELINUX_BOOTPARAM_VALUE. Since explicit ordering via CONFIG_LSM or "lsm=" will define whether an LSM is enabled or not, this CONFIG will become effectively ignored, so remove it. However, in order to stay backward-compatible with "security=selinux", the enable variable defaults to true. Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUEKees Cook2019-01-082-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for removing CONFIG_DEFAULT_SECURITY, this removes the soon-to-be redundant SECURITY_APPARMOR_BOOTPARAM_VALUE. Since explicit ordering via CONFIG_LSM or "lsm=" will define whether an LSM is enabled or not, this CONFIG will become effectively ignored, so remove it. However, in order to stay backward-compatible with "security=apparmor", the enable variable defaults to true. Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Separate idea of "major" LSM from "exclusive" LSMKees Cook2019-01-085-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to both support old "security=" Legacy Major LSM selection, and handling real exclusivity, this creates LSM_FLAG_EXCLUSIVE and updates the selection logic to handle them. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | LSM: Refactor "security=" in terms of enable/disableKees Cook2019-01-081-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For what are marked as the Legacy Major LSMs, make them effectively exclusive when selected on the "security=" boot parameter, to handle the future case of when a previously major LSMs become non-exclusive (e.g. when TOMOYO starts blob-sharing). Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | LSM: Prepare for reorganizing "security=" logicKees Cook2019-01-081-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This moves the string handling for "security=" boot parameter into a stored pointer instead of a string duplicate. This will allow easier handling of the string when switching logic to use the coming enable/disable infrastructure. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: John Johansen <john.johansen@canonical.com>
| * | | | LSM: Tie enabling logic to presence in ordered listKees Cook2019-01-081-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, any LSM without an enable storage variable was considered enabled. This inverts the logic and sets defaults to true only if the LSM gets added to the ordered initialization list. (And an exception continues for the major LSMs until they are integrated into the ordered initialization in a later patch.) Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Introduce "lsm=" for boottime LSM selectionKees Cook2019-01-082-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide a way to explicitly choose LSM initialization order via the new "lsm=" comma-separated list of LSMs. Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Introduce CONFIG_LSMKees Cook2019-01-082-5/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a way to declare LSM initialization order via the new CONFIG_LSM. Currently only non-major LSMs are recognized. This will be expanded in future patches. Signed-off-by: Kees Cook <keescook@chromium.org>
| * | | | LSM: Build ordered list of LSMs to initializeKees Cook2019-01-081-5/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This constructs an ordered list of LSMs to initialize, using a hard-coded list of only "integrity": minor LSMs continue to have direct hook calls, and major LSMs continue to initialize separately. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
| * | | | LSM: Lift LSM selection out of individual LSMsKees Cook2019-01-085-52/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As a prerequisite to adjusting LSM selection logic in the future, this moves the selection logic up out of the individual major LSMs, making their init functions only run when actually enabled. This considers all LSMs enabled by default unless they specified an external "enable" variable. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: John Johansen <john.johansen@canonical.com>
| * | | | LSM: Plumb visibility into optional "enabled" stateKees Cook2019-01-082-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for lifting the "is this LSM enabled?" logic out of the individual LSMs, pass in any special enabled state tracking (as needed for SELinux, AppArmor, and LoadPin). This should be an "int" to include handling any future cases where "enabled" is exposed via sysctl which has no "bool" type. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: John Johansen <john.johansen@canonical.com>
| * | | | LSM: Provide separate ordered initializationKees Cook2019-01-081-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a place for ordered LSMs to be initialized, separate from the "major" LSMs. This is mainly a copy/paste from major_lsm_init() to ordered_lsm_init(), but it will change drastically in later patches. What is not obvious in the patch is that this change moves the integrity LSM from major_lsm_init() into ordered_lsm_init(), since it is not marked with the LSM_FLAG_LEGACY_MAJOR. As it is the only LSM in the "ordered" list, there is no reordering yet created. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: John Johansen <john.johansen@canonical.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-23 16:32:26 +0000