6d9c939dbe
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>
49 lines
2.1 KiB
ReStructuredText
49 lines
2.1 KiB
ReStructuredText
===========================
|
|
Linux Security Module Usage
|
|
===========================
|
|
|
|
The Linux Security Module (LSM) framework provides a mechanism for
|
|
various security checks to be hooked by new kernel extensions. The name
|
|
"module" is a bit of a misnomer since these extensions are not actually
|
|
loadable kernel modules. Instead, they are selectable at build-time via
|
|
CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the
|
|
``"security=..."`` kernel command line argument, in the case where multiple
|
|
LSMs were built into a given kernel.
|
|
|
|
The primary users of the LSM interface are Mandatory Access Control
|
|
(MAC) extensions which provide a comprehensive security policy. Examples
|
|
include SELinux, Smack, Tomoyo, and AppArmor. In addition to the larger
|
|
MAC extensions, other extensions can be built using the LSM to provide
|
|
specific changes to system operation when these tweaks are not available
|
|
in the core functionality of Linux itself.
|
|
|
|
The Linux capabilities modules will always be included. This may be
|
|
followed by any number of "minor" modules and at most one "major" module.
|
|
For more details on capabilities, see ``capabilities(7)`` in the Linux
|
|
man-pages project.
|
|
|
|
A list of the active security modules can be found by reading
|
|
``/sys/kernel/security/lsm``. This is a comma separated list, and
|
|
will always include the capability module. The list reflects the
|
|
order in which checks are made. The capability module will always
|
|
be first, followed by any "minor" modules (e.g. Yama) and then
|
|
the one "major" module (e.g. SELinux) if there is one configured.
|
|
|
|
Process attributes associated with "major" security modules should
|
|
be accessed and maintained using the special files in ``/proc/.../attr``.
|
|
A security module may maintain a module specific subdirectory there,
|
|
named after the module. ``/proc/.../attr/smack`` is provided by the Smack
|
|
security module and contains all its special files. The files directly
|
|
in ``/proc/.../attr`` remain as legacy interfaces for modules that provide
|
|
subdirectories.
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
apparmor
|
|
LoadPin
|
|
SELinux
|
|
Smack
|
|
tomoyo
|
|
Yama
|