[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+BoPiy_YNgS4MC9vue8UDWZ5bwhpCO=bnvbgucsNGeqQ@mail.gmail.com>
Date: Mon, 13 Feb 2017 13:49:11 -0800
From: Kees Cook <keescook@...omium.org>
To: Casey Schaufler <casey@...aufler-ca.com>
Cc: Stephen Smalley <sds@...ho.nsa.gov>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
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 in
SELinux and Smack as __ro_after_init
On Mon, Feb 13, 2017 at 1:32 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> On 2/13/2017 1:03 PM, Stephen Smalley wrote:
>> On Mon, 2017-02-13 at 09:29 -0800, Kees Cook wrote:
>>> On Mon, Feb 13, 2017 at 3:29 AM, Tetsuo Handa
>>> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>>> James Morris wrote:
>>>>> Both SELinux and Smack register Netfilter operations during init,
>>>>> which then don't change. Mark these ops as __ro_after_init.
>>>>>
>>>>> Signed-off-by: James Morris <james.l.morris@...cle.com>
>>>> This patch breaks CONFIG_SECURITY_SELINUX_DISABLE=y +
>>>> SELINUX=disabled in /etc/selinux/config case,
>>>> doesn't it? Although I heard that SELinux is planning to remove
>>>> CONFIG_SECURITY_SELINUX_DISABLE,
>>>> CONFIG_SECURITY_SELINUX_DISABLE is valid as of current linux-
>>>> security.git#next .
>>> We could fold that removal into this series?
>> I'm personally in favor of removing it, but that support was originally
>> requested by the Fedora distro folks on the grounds that it is too
>> painful to manage kernel boot parameters on some platforms, and
>> therefore they needed an alternative to booting with selinux=0 on the
>> kernel command line. The documented way to disable SELinux on such
>> distros is through the use of /etc/selinux/config SELINUX=disabled,
>> which relies on this mechanism. So you'd have to work through removal
>> with the distro folks.
>>
>> Maybe in the interim we could just wrap the ro-after-init markings
>> under a conditional dependent on !CONFIG_SECURITY_SELINUX_DISABLE so
>> that systems (e.g. Android) that do not rely on this feature could
>> benefit.
>
> 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
?
-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.
