summaryrefslogtreecommitdiffstats
path: root/security (follow)
Commit message (Collapse)AuthorAgeFilesLines
* tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()Roberto Sassu2019-02-134-9/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest. This patch replaces the hash parameter of tpm_pcr_extend() with an array of tpm_digest structures, so that the caller can provide a digest for each PCR bank currently allocated in the TPM. tpm_pcr_extend() will not extend banks for which no digest was provided, as it happened before this patch, but instead it requires that callers provide the full set of digests. Since the number of digests will always be chip->nr_allocated_banks, the count parameter has been removed. Due to the API change, ima_pcr_extend() and pcrlock() have been modified. Since the number of allocated banks is not known in advance, the memory for the digests must be dynamically allocated. To avoid performance degradation and to avoid that a PCR extend is not done due to lack of memory, the array of tpm_digest structures is allocated by the users of the TPM driver at initialization time. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Mimi Zohar <zohar@linux.ibm.com> (on x86 for TPM 1.2 & PTT TPM 2.0) Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
* KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()Roberto Sassu2019-02-131-14/+24
| | | | | | | | | | | | | | | When crypto agility support will be added to the TPM driver, users of the driver have to retrieve the allocated banks from chip->allocated_banks and use this information to prepare the array of tpm_digest structures to be passed to tpm_pcr_extend(). This patch retrieves a tpm_chip pointer from tpm_default_chip() so that the pointer can be used to prepare the array of tpm_digest structures. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
* tpm: retrieve digest size of unknown algorithms with PCR readRoberto Sassu2019-02-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the TPM driver retrieves the digest size from a table mapping TPM algorithms identifiers to identifiers defined by the crypto subsystem. If the algorithm is not defined by the latter, the digest size can be retrieved from the output of the PCR read command. The patch modifies the definition of tpm_pcr_read() and tpm2_pcr_read() to pass the desired hash algorithm and obtain the digest size at TPM startup. Algorithms and corresponding digest sizes are stored in the new structure tpm_bank_info, member of tpm_chip, so that the information can be used by other kernel subsystems. tpm_bank_info contains: the TPM algorithm identifier, necessary to generate the event log as defined by Trusted Computing Group (TCG); the digest size, to pad/truncate a digest calculated with a different algorithm; the crypto subsystem identifier, to calculate the digest of event data. This patch also protects against data corruption that could happen in the bus, by checking that the digest size returned by the TPM during a PCR read matches the size of the algorithm passed to tpm2_pcr_read(). For the initial PCR read, when digest sizes are not yet available, this patch ensures that the amount of data copied from the output returned by the TPM does not exceed the size of the array data are copied to. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
* LSM: SafeSetID: remove unused includeMicah Morton2019-01-301-1/+0
| | | | | | | | | | | 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>
* LSM: SafeSetID: 'depend' on CONFIG_SECURITYMicah Morton2019-01-291-0/+2
| | | | | | | | | This patch changes the Kconfig file for the SafeSetID LSM to depend on CONFIG_SECURITY as well as select CONFIG_SECURITYFS, since the policies for the LSM are configured through writing to securityfs. Signed-off-by: Micah Morton <mortonm@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
* 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-231-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-231-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-231-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.
| * Merge branch 'fixes-v5.0-rc2' of ↵Linus Torvalds2019-01-172-1/+10
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull security subsystem fixes from James Morris: "Fixes for the security subsystem. The first (by Casey actually - it's misattributed) fixes a regression introduced with the LSM stacking changes" * 'fixes-v5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: LSM: Check for NULL cred-security on free Yama: Check for pid death before checking ancestry seccomp: fix UAF in user-trap code
| | * LSM: Check for NULL cred-security on freeJames Morris2019-01-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From: Casey Schaufler <casey@schaufler-ca.com> Check that the cred security blob has been set before trying to clean it up. There is a case during credential initialization that could result in this. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Acked-by: John Johansen <john.johansen@canonical.com> Signed-off-by: James Morris <james.morris@microsoft.com> Reported-by: syzbot+69ca07954461f189e808@syzkaller.appspotmail.com
| | * Yama: Check for pid death before checking ancestryKees Cook2019-01-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's possible that a pid has died before we take the rcu lock, in which case we can't walk the ancestry list as it may be detached. Instead, check for death first before doing the walk. Reported-by: syzbot+a9ac39bf55329e206219@syzkaller.appspotmail.com Fixes: 2d514487faf1 ("security: Yama LSM") Cc: stable@vger.kernel.org Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: James Morris <james.morris@microsoft.com>
| * | Merge tag 'selinux-pr-20190115' of ↵Linus Torvalds2019-01-161-1/+2
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux Pull SELinux fix from Paul Moore: "One small patch to fix a potential NULL dereference on a failed SELinux policy load" * tag 'selinux-pr-20190115' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: fix GPF on invalid policy
| | * selinux: fix GPF on invalid policyStephen Smalley2019-01-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | levdatum->level can be NULL if we encounter an error while loading the policy during sens_read prior to initializing it. Make sure sens_destroy handles that case correctly. Reported-by: syzbot+6664500f0f18f07a5c0e@syzkaller.appspotmail.com Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>
* | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 21:27:46 +0100