Message-ID: <CAGXu5j+NskN80MuJpt1csDVHjQw0yDJxuyg0G8OQHMJ1qiQ21g@mail.gmail.com>
Date:	Tue, 21 Jul 2015 17:06:46 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Josh Boyer <jwboyer@...oraproject.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	James Morris <james.l.morris@...cle.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Yama: remove needless CONFIG_SECURITY_YAMA_STACKED

On Tue, Jul 21, 2015 at 5:03 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 7/21/2015 3:41 PM, Kees Cook wrote:
>> On Tue, Jul 21, 2015 at 1:56 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> On 7/21/2015 1:09 PM, Josh Boyer wrote:
>>>> On Tue, Jul 21, 2015 at 3:48 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>>>> On 7/21/2015 12:09 PM, Kees Cook wrote:
>>>>>> Now that minor LSMs can cleanly stack with major LSMs, remove the unneeded
>>>>>> config for Yama to be made to explicitly stack. Just selecting the main
>>>>>> Yama CONFIG will allow it to work, regardless of the major LSM. Since
>>>>>> distros using Yama are already forcing it to stack, this is effectively
>>>>>> a no-op change.
>>>>> Today I can compile in all LSMs including Yama and pick the one I want.
>>>>> If we made your change it would be impossible to build in Yama and not
>>>>> use it. I suggest we hold off until after the security summit discussion
>>>> This is true, but it's also true regardless of stacking.  If Yama had
>>>> a CONFIG_SECURITY_YAMA_ENABLED (or whatever bikeshed color), then you
>>>> could enable Yama and not use it, yes?  It would also allow people to
>>>> default it as disabled, but then enable it at runtime via the
>>>> ptrace_scope sysctl.
>>> The way Kees proposed it you would *always* get Yama stacked with
>>> your other module if you compile Yama in. Thus, If I compile in
>>> SELinux and Yama I cannot run SELinux without Yama. Today, I can
>> Yama is entirely controllable from sysctl, so you could build it in
>> and set the ptrace_scope setting to 0 at boot. It's already being
>> built into distro kernels this way (via the STACKING config), so this
>> change is effectively no different.
>>
>>> compile SELinux and Yama in but run only SELinux. My suggestion is
>>> to wait until we can specify the modules to use before we remove
>>> the kconfig option that provides that facility today.
>> I'm happy to wait, but I'm still going to send my other 2 "minor" LSMs
>> before LSS. :) Neither of them would be built into a kernel without
>> wanting their functionality, so they'll have the stack "always on"
>> semantics if their CONFIG is selected.
>
> Fair enough then. I'll withdraw my objection. One question comes
> to mind, and that is how are you planning to order them? I put
> Yama ahead of the "major" modules because that was how it had been
> stacked previously. Let's assume that the capability module stays
> in the first position. Are you planning to put your new modules
> before Yama, before the "major" module(s) or at the end?

It shouldn't matter, IMO. Though perhaps that's a mistake, and we
should make sure all "minor" LSMs go first? As I have it, it'd be in
link order, which is likely not "stable", so perhaps I've just talked
myself out of "it shouldn't matter".

-Kees

-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists