[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jK-D6VzcxQ+Jxo0=uQnu3rhkO6mqCpozwqxnELjuhn82g@mail.gmail.com>
Date: Mon, 13 Feb 2017 14:09:03 -0800
From: Kees Cook <keescook@...omium.org>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Casey Schaufler <casey@...aufler-ca.com>, Stephen Smalley <sds@...ho.nsa.gov>,
James Morris <jmorris@...ei.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Paul Moore <paul@...l-moore.com>
Subject: Re: Re: [RFC PATCH 2/4] security: mark nf ops
inSELinux and Smack as __ro_after_init
On Mon, Feb 13, 2017 at 2:05 PM, Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
> Kees Cook wrote:
>> On Mon, Feb 13, 2017 at 1:32 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>> > If we changed CONFIG_SECURITY_SELINUX_DISABLE to
>> > CONFIG_SECURITY_DYNAMIC_MODULES and put the __ro_after_init
>> > under !CONFIG_SECURITY_DYNAMIC_MODULES we solve both the
>> > current and potential future issues.
>>
>> Something like...
>>
>> #ifdef CONFIG_SECURITY_DYNAMIC_LSM
>> # define lsm_ro_after_init __ro_after_init
>> # define lsm_const const
>> #else
>> # define lsm_ro_after_init
>> # define lsm_const
>> #endif
>>
>> ?
>
> Fedora/RHEL won't use CONFIG_SECURITY_DYNAMIC_LSM=y whereas
> LKM based LSMs are targeted for such distributions.
>
> I don't worry much about Android, for manufactures who ship their
> products with TOMOYO enabled can rebuild their kernels. But asking
> for rebuild of Fedora/RHEL kernels to end users is too painful.
I thought the argument was that Fedora WOULD ship that way, since it
needs to have the run-time selinux disabling feature?
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
