[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEiveUdQYbx8d9B68n2M12fhu3s8web3zCvkc-C9FWtNnbELuA@mail.gmail.com>
Date: Mon, 24 Apr 2017 16:25:40 +0200
From: Djalal Harouni <tixxdz@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Andy Lutomirski <luto@...nel.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 Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keescook@...omium.org> wrote:
> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski <luto@...nel.org> wrote:
>> 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:
>>>
[...]
>>> * 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.
>
> How about CAP_SYS_ADMIN || no_new_privs?
>
> -Kees
>
Yes I can update as per Andy suggestion to require privileges inside
the calling namespace to set prctl. Other options that are not prctl
based have more variants, that make them hard to use.
So I would got with CAP_SYS_ADMIN in the calling userns ||
no_new_privs , I would have said CAP_SYS_MODULE in the userns but it
seems better to standardize on CAP_SYS_ADMIN to set the prctl.
--
tixxdz
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.
