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>

This adds a flag for the current "major" LSMs to distinguish them when
we have a universal method for ordering all LSMs. It's called "legacy"
since the distinction of "major" will go away in the blob-sharing world.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NCasey Schaufler <casey@schaufler-ca.com>
Reviewed-by: NJohn Johansen <john.johansen@canonical.com>

Pull more Kbuild updates from Masahiro Yamada:

 - improve boolinit.cocci and use_after_iter.cocci semantic patches

 - fix alignment for kallsyms

 - move 'asm goto' compiler test to Kconfig and clean up jump_label
   CONFIG option

 - generate asm-generic wrappers automatically if arch does not
   implement mandatory UAPI headers

 - remove redundant generic-y defines

 - misc cleanups

* tag 'kbuild-v4.21-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  kconfig: rename generated .*conf-cfg to *conf-cfg
  kbuild: remove unnecessary stubs for archheader and archscripts
  kbuild: use assignment instead of define ... endef for filechk_* rules
  arch: remove redundant UAPI generic-y defines
  kbuild: generate asm-generic wrappers if mandatory headers are missing
  arch: remove stale comments "UAPI Header export list"
  riscv: remove redundant kernel-space generic-y
  kbuild: change filechk to surround the given command with { }
  kbuild: remove redundant target cleaning on failure
  kbuild: clean up rule_dtc_dt_yaml
  kbuild: remove UIMAGE_IN and UIMAGE_OUT
  jump_label: move 'asm goto' support test to Kconfig
  kallsyms: lower alignment on ARM
  scripts: coccinelle: boolinit: drop warnings on named constants
  scripts: coccinelle: check for redeclaration
  kconfig: remove unused "file" field of yylval union
  nds32: remove redundant kernel-space generic-y
  nios2: remove unneeded HAS_DMA define

Pull perf tooling updates form Ingo Molnar:
 "A final batch of perf tooling changes: mostly fixes and small
  improvements"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (29 commits)
  perf session: Add comment for perf_session__register_idle_thread()
  perf thread-stack: Fix thread stack processing for the idle task
  perf thread-stack: Allocate an array of thread stacks
  perf thread-stack: Factor out thread_stack__init()
  perf thread-stack: Allow for a thread stack array
  perf thread-stack: Avoid direct reference to the thread's stack
  perf thread-stack: Tidy thread_stack__bottom() usage
  perf thread-stack: Simplify some code in thread_stack__process()
  tools gpio: Allow overriding CFLAGS
  tools power turbostat: Override CFLAGS assignments and add LDFLAGS to build command
  tools thermal tmon: Allow overriding CFLAGS assignments
  tools power x86_energy_perf_policy: Override CFLAGS assignments and add LDFLAGS to build command
  perf c2c: Increase the HITM ratio limit for displayed cachelines
  perf c2c: Change the default coalesce setup
  perf trace beauty ioctl: Beautify USBDEVFS_ commands
  perf trace beauty: Export function to get the files for a thread
  perf trace: Wire up ioctl's USBDEBFS_ cmd table generator
  perf beauty ioctl: Add generator for USBDEVFS_ ioctl commands
  tools headers uapi: Grab a copy of usbdevice_fs.h
  perf trace: Store the major number for a file when storing its pathname
  ...

The semantics of what "in core" means for the mincore() system call are
somewhat unclear, but Linux has always (since 2.3.52, which is when
mincore() was initially done) treated it as "page is available in page
cache" rather than "page is mapped in the mapping".

The problem with that traditional semantic is that it exposes a lot of
system cache state that it really probably shouldn't, and that users
shouldn't really even care about.

So let's try to avoid that information leak by simply changing the
semantics to be that mincore() counts actual mapped pages, not pages
that might be cheaply mapped if they were faulted (note the "might be"
part of the old semantics: being in the cache doesn't actually guarantee
that you can access them without IO anyway, since things like network
filesystems may have to revalidate the cache before use).

In many ways the old semantics were somewhat insane even aside from the
information leak issue.  From the very beginning (and that beginning is
a long time ago: 2.3.52 was released in March 2000, I think), the code
had a comment saying

  Later we can get more picky about what "in core" means precisely.

and this is that "later".  Admittedly it is much later than is really
comfortable.

NOTE! This is a real semantic change, and it is for example known to
change the output of "fincore", since that program literally does a
mmmap without populating it, and then doing "mincore()" on that mapping
that doesn't actually have any pages in it.

I'm hoping that nobody actually has any workflow that cares, and the
info leak is real.

We may have to do something different if it turns out that people have
valid reasons to want the old semantics, and if we can limit the
information leak sanely.

Cc: Kevin Easton <kevin@guarana.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Masatake YAMATO <yamato@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>