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: NMicah Morton <mortonm@chromium.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NJames Morris <james.morris@microsoft.com>

Merge tag 'blob-stacking-security-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into next-general

LSM: Module stacking for SARA and Landlock

The combined series of LSM refactoring and addition of blob-sharing for
SARA and Landlock.

From Casey:

v5: Include Kees Cook's rework of the lsm command
    line interface.
v4: Finer granularity in the patches and other
    cleanups suggested by Kees Cook.
    Removed dead code created by the removal of SELinux
    credential blob poisoning.
v3: Add ipc blob for SARA and task blob for Landlock.
    Removing the SELinux cred blob pointer poisoning
    results selinux_is_enabled() being unused, so it and
    all it's overhead has been removed.
    Broke up the cred infrastructure patch.
v2: Reduce the patchset to what is required to support
    the proposed SARA and LandLock security modules

The SARA security module is intended to be used
in conjunction with other security modules. It requires
state to be maintained for the credential, which
in turn requires a mechanism for sharing the credential
security blob. It also uses the ipc security blob. The
module also requires mechanism for user space manipulation
of the credential information, hence an additional
subdirectory in /proc/.../attr.

The LandLock security module provides user configurable
policy in the secmark mechanism. It requires data in
the credential, file, inode and task security blobs. For
this to be used along side the existing "major" security
modules mechanism for sharing these blobs are provided.

A side effect of providing sharing of the crendential
security blob is that the TOMOYO module can be used at
the same time as the other "major" modules.

The mechanism for configuring which security modules are
enabled has to change when stacking in enabled. Any
module that uses just the security blobs that are shared
can be selected. Additionally, one other "major" module
can be selected.

The security module stacking issues around networking and
IPC are not addressed here as they are beyond what is
required for TOMOYO, SARA and LandLock.

Linux 5.0-rc1

Sync to pick up LSM stacking work (which is based on -rc1).

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: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the inode->i_security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the inode->i_security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the file->f_security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the file->f_security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the cred->security pointer directly.
Provide helper functions that provide the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the cred->security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the cred->security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

Don't use the cred->security pointer directly.
Provide a helper function that provides the security blob pointer.
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
[kees: adjusted for ordered init series]
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>

This converts capabilities to use the new LSM_ORDER_FIRST position.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NKees Cook <keescook@chromium.org>

This converts Yama from being a direct "minor" LSM into an ordered LSM.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>

This converts LoadPin from being a direct "minor" LSM into an ordered LSM.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NKees Cook <keescook@chromium.org>

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: NKees Cook <keescook@chromium.org>
Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NKees Cook <keescook@chromium.org>

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: NKees Cook <keescook@chromium.org>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>

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: NKees Cook <keescook@chromium.org>

Provide a way to explicitly choose LSM initialization order via the new
"lsm=" comma-separated list of LSMs.
Signed-off-by: NKees Cook <keescook@chromium.org>

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: NKees Cook <keescook@chromium.org>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>

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: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>