linux-kernel - Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Nov 2017 12:08:12 -0800
From:   Kees Cook <keescook@...omium.org>
To:     "Theodore Ts'o" <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Djalal Harouni <tixxdz@...il.com>
Cc:     Jonathan Corbet <corbet@....net>,
        James Morris <james.l.morris@...cle.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>,
        Geo Kozey <geokozey@...lfence.com>
Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use
 request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 11:32 AM, Theodore Ts'o <tytso@....edu> wrote:
> On Tue, Nov 28, 2017 at 01:16:59PM +0100, Geo Kozey wrote:
>>
>> Userspace can be configured in a way which is compatible with those
>> changes being on the same as it can be configured to work with
>> selinux. That means on distro level or sysadmin level it's a
>> valuable tool. It's better than nothing and it's better than using
>> some out-of-tree patches instead. Switching one sysctl would make
>> their life easier.
>
> If *selinux* can opt-in to something more stringent, such that when
> you upgrade to a new version of selinux which enables something which
> breaks all modules unless you set up the rules corretly, I don't see a
> problem with it.  It might force distributions not to go to the latest
> version of SELinux because users get cranky when their systems get
> broken, but for people like me, who *still* don't use SELinux because
> every few years, i try to enable on my development laptop running
> Debian, watch ***far*** too much stuff break. and then turn it off
> again.  So tieing it to SELinux (as far as I am concerned) reduces it to
> a previously unsolved problem.  :-)
>
> But that's different from opting it on by default for non-SELinux
> users.  To which I can only say, "Please, No."

I don't want to see this tied to SELinux because it narrows the
audience, and SELinux still hasn't solved their issues in containers.
I think the per-task setting is sufficient.

Linus, are you okay with this series if the global sysctl gets dropped?

-Kees

-- 
Kees Cook
Pixel Security