[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUT73CcPQx2T=1zWbOUhw9r-c_YqXw5-KTwxgWPgXuTwA@mail.gmail.com>
Date: Fri, 21 Apr 2017 23:51:44 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Djalal Harouni <tixxdz@...il.com>
Cc: Andy Lutomirski <luto@...nel.org>, Kees Cook <keescook@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
LSM List <linux-security-module@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>, Dongsu Park <dpark@...teo.net>,
Casey Schaufler <casey@...aufler-ca.com>, James Morris <james.l.morris@...cle.com>,
Paul Moore <paul@...l-moore.com>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jonathan Corbet <corbet@....net>,
Jessica Yu <jeyu@...hat.com>, Rusty Russell <rusty@...tcorp.com.au>,
Arnaldo Carvalho de Melo <acme@...hat.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Ingo Molnar <mingo@...nel.org>,
belakhdar abdeldjalil <zendyani@...il.com>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules
autoload restriction
On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni <tixxdz@...il.com> wrote:
> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <luto@...nel.org> wrote:
> [...]
>>>> I personally like my implicit_rights idea, and it might be interesting
>>>> to prototype it.
>>>
>>> I don't like blocking a needed feature behind a large super-feature
>>> that doesn't exist yet. We'd be able to refactor this code into using
>>> such a thing in the future, so I'd prefer to move ahead with this
>>> since it would stop actual exploits.
>>
>> I don't think the super-feature is so hard, and I think we should not
>> add the per-task thing the way it's done in this patch. Let's not add
>> per-task things where the best argument for their security is "not
>> sure how it would be exploited".
>
> Actually the XFRM framework CVE-2017-7184 [1] is one real example, of
> course there are others. The exploit was used on a generic distro
> during a security contest that distro is Ubuntu. That distro will
> never provide a module autoloading restriction by default to not harm
> it's users. Consumers or containers/sandboxes then can run their
> confined apps using such facilities.
>
> These bugs will stay in embedded devices that use these generic
> distros for ever.
>
>> Anyway, I think the sysctl is really the important bit. The per-task
>> setting is icing on the cake IMO. One upon a time autoload was more
>> important, but these days modaliases are supposed to do most of the
>> work. I bet that modern distros don't need unprivileged autoload at
>> all.
>
> Actually I think they do and we can't just change that. Users may
> depend on it, it is a well established facility.
>
> Now the other problem is CAP_NET_ADMIN which does lot of things, it is
> more like the CAP_SYS_ADMIN.
>
> This is a quick list that I got from only the past months, I'm pretty
> sure there are more:
>
> * DCCP use after free CVE-2017-6074
> * n_hldc CVE-2017-2636
> * XFRM framework CVE-2017-7184
> * L2TPv3 CVE-2016-10200
>
> Most of these need CAP_NET_ADMIN to be autoloaded, however we also
> need CAP_NET_ADMIN for other things... therefore it is better to have
> an extra facility that could coexist with CAP_NET_ADMIN and other
> sandbox features.
>
I agree that the feature is important, but I think your implementation
is needlessly dangerous. I imagine that the main uses that you care
about involve containers. How about doing it in a safer way that
works for containers? I can think of a few. For example:
1. A sysctl that, if set, prevents autoloading outside the root
userns. This isn't very flexible at all, but it might work.
2. Your patch, but require privilege within the calling namespace to
set the prctl.
3. A per-user-ns sysctl.
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.
