From: Casey Schaufler <casey@schaufler-ca.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: LKLM <linux-kernel@vger.kernel.org>,
LSM <linux-security-module@vger.kernel.org>,
SE Linux <selinux@tycho.nsa.gov>,
James Morris <jmorris@namei.org>,
John Johansen <john.johansen@canonical.com>,
Eric Paris <eparis@redhat.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Kees Cook <keescook@chromium.org>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v14 6/6] LSM: Multiple LSM Documentation and cleanup
Date: Sun, 28 Jul 2013 11:46:46 -0700 [thread overview]
Message-ID: <51F56716.8060707@schaufler-ca.com> (raw)
In-Reply-To: <51F3036D.3070900@infradead.org>
On 7/26/2013 4:17 PM, Randy Dunlap wrote:
> On 07/25/13 11:32, Casey Schaufler wrote:
>> Subject: [PATCH v14 6/6] LSM: Multiple LSM Documentation and cleanup
>>
>> Add documentation and remove the obsolete capability LSM.
>> Clean up some comments in security.h
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>>
>> ---
>> Documentation/security/LSM.txt | 56 +-
>> include/linux/security.h | 48 +-
>> security/Makefile | 1 -
>> security/capability.c | 1106 ----------------------------------------
>> 4 files changed, 77 insertions(+), 1134 deletions(-)
>>
>> diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
>> index c335a76..69cf466 100644
>> --- a/Documentation/security/LSM.txt
>> +++ b/Documentation/security/LSM.txt
>> @@ -7,20 +7,56 @@ various security checks to be hooked by new kernel extensions. The name
>> 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.
>> +LSMs were built into a given kernel. The names of the active LSMs
>> +can be read from /sys/kernel/security/lsm.
>> +
>> +Both CONFIG_DEFAULT_SECURITY and the "security=" option take a comma
>> +separated list of LSM names. The LSM hooks are invoked in the order
>> +specified. All hooks provided are invoked regardless of the outcome
>> +of preceding hooks. Hooks that return success or failure results
>> +return success if all of the LSM provided hooks succeed and the error
>> +code of the last failing hook on error.
>> +
>> +Information from an LSM can come in one of two forms. The raw data
>> +used by the LSM is typically the preferred form. SELinux contexts and
>> +Smack labels are examples of raw LSM data. If the data from multiple
>> +LSMs is presented together it will be in the form:
>> +
>> + lsmname='value'[lsmname='value']...
> no commas? just (made up example):
>
> smack='label'selinux='notstrict'
That's correct. No commas. Because all values are quoted commas
are unnecessary. If I want the SELinux portion of a context I can call
sscanf(source, "selinux='%[^']'", result);
and comma separation helps not a bit.
>> +
>> +Interfaces that accept LSM data as input accept this format as well,
>> +passing only the relevant portion of the data to each LSM.
>> +
>> +The /proc filesystem attribute interface supports files from a time
>> +when only one LSM could be used at a time. CONFIG_PRESENT_SECURITY
>> +defines which LSM uses these interfaces. The name of this LSM can be
>> +read from /sys/kernel/security/present. There are also LSM identified
>> +interfaces which should be used in preference to the undifferentiated
>> +interfaces. The attribute interface "context" always provides the
>> +data from all LSMs that maintain it in the lsmname='value' format.
>> +
>> +The three networking mechanisms supporting LSM attributes are
>> +restricted to providing those attributes for a single LSM each.
>> +CONFIG_SECMARK_LSM specifies which LSM will provide hooks for the
>> +secmark mechanism. CONFIG_NETLABEL_LSM specifies which LSM hooks
>> +are used by NetLabel to provide IPv4 CIPSO headers. CONFIG_XFRM_LSM
>> +specifies the LSM providing xfrm hooks. CONFIG_PEERSEC_LSM allows
>> +for either a specific LSM to provide data with SO_PEERSEC or for
>> +all LSMs that provide data to do so.
>> +
>> +The Linux capabilities system is used in conjunction with any LSMs.
>> +LSM hooks are called after the capability checks in most cases,
> ^^^^^
>> +but after in a small number of cases. All LSM hooks need to be aware
> ^^^^^
>
> one of these 'after's should be 'before' ??
Yup. The latter should in fact be "before".
>> +of the potential interactions with the capability system. For more
>> +details on capabilities, see capabilities(7) in the Linux man-pages
>> +project.
>>
>> 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.
>> -
>> -Without a specific LSM built into the kernel, the default LSM will be the
>> -Linux capabilities system. Most LSMs choose to extend the capabilities
>> -system, building their checks on top of the defined capability hooks.
>> -For more details on capabilities, see capabilities(7) in the Linux
>> -man-pages project.
>> +MAC extensions, other extensions such as Yama 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.
>>
>> Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent,
>> a new LSM is accepted into the kernel when its intent (a description of
>>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: LKLM <linux-kernel@vger.kernel.org>,
LSM <linux-security-module@vger.kernel.org>,
SE Linux <selinux@tycho.nsa.gov>,
James Morris <jmorris@namei.org>,
John Johansen <john.johansen@canonical.com>,
Eric Paris <eparis@redhat.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Kees Cook <keescook@chromium.org>,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v14 6/6] LSM: Multiple LSM Documentation and cleanup
Date: Sun, 28 Jul 2013 11:46:46 -0700 [thread overview]
Message-ID: <51F56716.8060707@schaufler-ca.com> (raw)
In-Reply-To: <51F3036D.3070900@infradead.org>
On 7/26/2013 4:17 PM, Randy Dunlap wrote:
> On 07/25/13 11:32, Casey Schaufler wrote:
>> Subject: [PATCH v14 6/6] LSM: Multiple LSM Documentation and cleanup
>>
>> Add documentation and remove the obsolete capability LSM.
>> Clean up some comments in security.h
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>>
>> ---
>> Documentation/security/LSM.txt | 56 +-
>> include/linux/security.h | 48 +-
>> security/Makefile | 1 -
>> security/capability.c | 1106 ----------------------------------------
>> 4 files changed, 77 insertions(+), 1134 deletions(-)
>>
>> diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt
>> index c335a76..69cf466 100644
>> --- a/Documentation/security/LSM.txt
>> +++ b/Documentation/security/LSM.txt
>> @@ -7,20 +7,56 @@ various security checks to be hooked by new kernel extensions. The name
>> 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.
>> +LSMs were built into a given kernel. The names of the active LSMs
>> +can be read from /sys/kernel/security/lsm.
>> +
>> +Both CONFIG_DEFAULT_SECURITY and the "security=" option take a comma
>> +separated list of LSM names. The LSM hooks are invoked in the order
>> +specified. All hooks provided are invoked regardless of the outcome
>> +of preceding hooks. Hooks that return success or failure results
>> +return success if all of the LSM provided hooks succeed and the error
>> +code of the last failing hook on error.
>> +
>> +Information from an LSM can come in one of two forms. The raw data
>> +used by the LSM is typically the preferred form. SELinux contexts and
>> +Smack labels are examples of raw LSM data. If the data from multiple
>> +LSMs is presented together it will be in the form:
>> +
>> + lsmname='value'[lsmname='value']...
> no commas? just (made up example):
>
> smack='label'selinux='notstrict'
That's correct. No commas. Because all values are quoted commas
are unnecessary. If I want the SELinux portion of a context I can call
sscanf(source, "selinux='%[^']'", result);
and comma separation helps not a bit.
>> +
>> +Interfaces that accept LSM data as input accept this format as well,
>> +passing only the relevant portion of the data to each LSM.
>> +
>> +The /proc filesystem attribute interface supports files from a time
>> +when only one LSM could be used at a time. CONFIG_PRESENT_SECURITY
>> +defines which LSM uses these interfaces. The name of this LSM can be
>> +read from /sys/kernel/security/present. There are also LSM identified
>> +interfaces which should be used in preference to the undifferentiated
>> +interfaces. The attribute interface "context" always provides the
>> +data from all LSMs that maintain it in the lsmname='value' format.
>> +
>> +The three networking mechanisms supporting LSM attributes are
>> +restricted to providing those attributes for a single LSM each.
>> +CONFIG_SECMARK_LSM specifies which LSM will provide hooks for the
>> +secmark mechanism. CONFIG_NETLABEL_LSM specifies which LSM hooks
>> +are used by NetLabel to provide IPv4 CIPSO headers. CONFIG_XFRM_LSM
>> +specifies the LSM providing xfrm hooks. CONFIG_PEERSEC_LSM allows
>> +for either a specific LSM to provide data with SO_PEERSEC or for
>> +all LSMs that provide data to do so.
>> +
>> +The Linux capabilities system is used in conjunction with any LSMs.
>> +LSM hooks are called after the capability checks in most cases,
> ^^^^^
>> +but after in a small number of cases. All LSM hooks need to be aware
> ^^^^^
>
> one of these 'after's should be 'before' ??
Yup. The latter should in fact be "before".
>> +of the potential interactions with the capability system. For more
>> +details on capabilities, see capabilities(7) in the Linux man-pages
>> +project.
>>
>> 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.
>> -
>> -Without a specific LSM built into the kernel, the default LSM will be the
>> -Linux capabilities system. Most LSMs choose to extend the capabilities
>> -system, building their checks on top of the defined capability hooks.
>> -For more details on capabilities, see capabilities(7) in the Linux
>> -man-pages project.
>> +MAC extensions, other extensions such as Yama 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.
>>
>> Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent,
>> a new LSM is accepted into the kernel when its intent (a description of
>>
next prev parent reply other threads:[~2013-07-28 18:47 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 18:22 [PATCH v14 0/6] LSM: Multiple concurrent LSMs Casey Schaufler
2013-07-25 18:22 ` Casey Schaufler
2013-07-25 18:32 ` [PATCH v14 1/6] LSM: Security blob abstraction Casey Schaufler
2013-07-25 18:32 ` Casey Schaufler
2013-07-29 21:15 ` Kees Cook
2013-07-30 1:49 ` Casey Schaufler
2013-07-30 1:49 ` Casey Schaufler
2013-07-25 18:32 ` [PATCH v14 2/6] LSM: Move the capability LSM into the hook handlers Casey Schaufler
2013-07-25 18:32 ` Casey Schaufler
2013-07-25 18:32 ` [PATCH v14 3/6] LSM: Explicit individual LSM associations Casey Schaufler
2013-07-25 18:32 ` Casey Schaufler
2013-07-29 20:51 ` Kees Cook
2013-07-30 1:48 ` Casey Schaufler
2013-07-30 1:48 ` Casey Schaufler
2013-07-30 22:08 ` Paul Moore
2013-07-30 22:08 ` Paul Moore
2013-07-31 16:22 ` Casey Schaufler
2013-07-31 16:22 ` Casey Schaufler
2013-07-31 19:39 ` Paul Moore
2013-07-31 19:39 ` Paul Moore
2013-07-31 21:21 ` Casey Schaufler
2013-07-31 21:21 ` Casey Schaufler
2013-08-01 18:35 ` Paul Moore
2013-08-01 18:35 ` Paul Moore
2013-08-01 18:52 ` Casey Schaufler
2013-08-01 18:52 ` Casey Schaufler
2013-08-01 21:30 ` Paul Moore
2013-08-01 21:30 ` Paul Moore
2013-08-01 22:15 ` Casey Schaufler
2013-08-01 22:15 ` Casey Schaufler
2013-08-01 22:18 ` Paul Moore
2013-08-01 22:18 ` Paul Moore
2013-07-25 18:32 ` [PATCH v14 4/6] LSM: List based multiple LSM hooks Casey Schaufler
2013-07-25 18:32 ` Casey Schaufler
2013-07-25 18:32 ` [PATCH v14 5/6] LSM: SO_PEERSEC configuration options Casey Schaufler
2013-07-25 18:32 ` Casey Schaufler
2013-07-30 21:47 ` Paul Moore
2013-07-30 21:47 ` Paul Moore
2013-07-31 15:45 ` Casey Schaufler
2013-07-31 15:45 ` Casey Schaufler
2013-07-31 17:56 ` Paul Moore
2013-07-31 17:56 ` Paul Moore
2013-07-25 18:32 ` [PATCH v14 6/6] LSM: Multiple LSM Documentation and cleanup Casey Schaufler
2013-07-25 18:32 ` Casey Schaufler
2013-07-26 23:17 ` Randy Dunlap
2013-07-28 18:46 ` Casey Schaufler [this message]
2013-07-28 18:46 ` Casey Schaufler
2013-08-01 2:48 ` [PATCH v14 0/6] LSM: Multiple concurrent LSMs Balbir Singh
2013-08-01 17:21 ` Casey Schaufler
2013-08-01 17:21 ` Casey Schaufler
2013-08-06 3:28 ` Balbir Singh
2013-08-06 6:30 ` Kees Cook
2013-08-06 22:25 ` Casey Schaufler
2013-08-06 22:25 ` Casey Schaufler
2013-08-06 22:36 ` Kees Cook
2013-08-27 2:29 ` Casey Schaufler
2013-08-27 2:29 ` Casey Schaufler
2013-08-28 15:55 ` Kees Cook
2013-09-05 18:48 ` Kees Cook
2013-09-06 6:44 ` Casey Schaufler
2013-09-06 6:44 ` Casey Schaufler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F56716.8060707@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rdunlap@infradead.org \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.