[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 Apr 2017 11:06:12 +0200
From: Djalal Harouni <tixxdz@...il.com>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Andy Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...ux-foundation.org>,
"Serge E. Hallyn" <serge@...lyn.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>, Arnaldo Carvalho de Melo <acme@...hat.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Ingo Molnar <mingo@...nel.org>, Zendyani <zendyani@...il.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules
autoload restriction
Hi Rusty,
On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> Djalal Harouni <tixxdz@...il.com> writes:
>> When value is (1), task must have CAP_SYS_MODULE to be able to trigger a
>> module auto-load operation, or CAP_NET_ADMIN for modules with a
>> 'netdev-%s' alias.
>
> Sorry, the magic 'netdev-' prefix is a crawling horror. To do this
Yes I agree, that's the not the best part. I added it for backward
compatibility since I did notice that some network daemon retain
CAP_NET_ADMIN for this case. The aim of the patches is to get modules
autoload covered with CAP_SYS_MODULE and make it more like explicit
modules loading.
> properly, you need to hand the capability (if any) from the
> request_module() call. Probably by adding a new request_module_cap and
> making request_module() call that, then fixing up the callers.
Hmm, sorry Rusty I'm a bit confused, when you refer to "callers", you
mean request_module() callers ?
If so, I'm not sure that the best thing here since it may defeat the
purpose of this feature if we allow to pass capabilities.
Right now we have modules autoload that can be triggered without
privileges, or with CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_MODULE...
and some caps may allow to load other modules to resolve symbols etc.
The public exploits did target CAP_NET_ADMIN, if we offer a way to
pass in capabilities it will be used it as it is the case now without
it, not to mention that some capabilities are overloaded, exploits
will continue for these ones.
The goal is to narrow modules autoload only to CAP_SYS_MODULE or
disable it completely for process trees. Later you can give
CAP_SYS_MODULE and you are sure that only /lib/modules/ will be
autoloaded, no arbitrary loads by using seccomp filter on module
syscalls, or separate the process in two one with CAP_SYS_MODULE and
the other with its own capabilities and feature use.
I also don't like that 'netdev-%s' but it is for compatibility for
specific cases, maybe there are others that we may have to add. But I
would prefer if we narrow it down to only CAP_SYS_MODULE.
How about I move all permission checks to security/commoncap.c
helpers, the module logic part will only contain set and read sysctl
"modules_autoload" and "task->modules_autoload" ?
I already added cap_kernel_module_request() which is called by
request_module(), so instead of counting on module to do the
permission check I will open code it inside
security/commoncap.c:cap_kernel_module_request() like other capability
helpers and note that CAP_NET_ADMIN 'netdev-%s' alias is only for
compatibility. This way we prevent that other capabilities get exposed
or targeted for exploitation. Do you think that this will work ?
Thanks!
> Cheers,
> Rusty.
--
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.
