linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Djalal Harouni <tixxdz@gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	kernel-hardening@lists.openwall.com,
	LSM List <linux-security-module@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Dongsu Park <dpark@posteo.net>,
	Casey Schaufler <casey@schaufler-ca.com>,
	James Morris <james.l.morris@oracle.com>,
	Paul Moore <paul@paul-moore.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Corbet <corbet@lwn.net>, Jessica Yu <jeyu@redhat.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Zendyani <zendyani@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction
Date: Wed, 26 Apr 2017 11:06:12 +0200	[thread overview]
Message-ID: <CAEiveUfVyLVrCgjniA+7eutv=OGQ2LwBCx0V7JLiySeJz3c5ZQ@mail.gmail.com> (raw)
In-Reply-To: <87r30ifmwz.fsf@rustcorp.com.au>

Hi Rusty,

On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> Djalal Harouni <tixxdz@gmail.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

  reply	other threads:[~2017-04-26  9:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 22:20 [PATCH v3 0/2] modules:capabilities: automatic module loading restrictions Djalal Harouni
2017-04-19 22:20 ` [PATCH v3 1/2] modules:capabilities: automatic module loading restriction Djalal Harouni
2017-04-19 23:16   ` Andy Lutomirski
2017-04-20  2:22   ` Ben Hutchings
2017-04-20 12:44     ` [kernel-hardening] " Djalal Harouni
2017-04-20 15:02       ` Ben Hutchings
     [not found]         ` <1492700543.31767.23.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2017-04-20 20:39           ` [kernel-hardening] " Djalal Harouni
     [not found]             ` <CAEiveUdFL53XyQpacmN6f8F28M0bLQDcetpRXJjrJ10vDmQi8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-20 21:28               ` Kees Cook
2017-04-19 22:20 ` [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction Djalal Harouni
2017-04-19 23:15   ` Andy Lutomirski
2017-04-19 23:43     ` Kees Cook
2017-04-20  2:41       ` Andy Lutomirski
     [not found]         ` <CALCETrUueOx1tqj+Ru93KGpy2HHR-A_GQ6DrAppiomkPTtX7Lw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-21 23:19           ` Kees Cook
2017-04-21 23:28             ` Andy Lutomirski
2017-04-21 23:40               ` Kees Cook
2017-04-21 23:51                 ` Andy Lutomirski
2017-04-22  0:12                   ` Djalal Harouni
     [not found]                     ` <CAEiveUcx8fwQgXdLPeMNsTjX2KPhQKH__a-XzcHko_1aCmh4sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-22  1:19                       ` Djalal Harouni
2017-04-22  6:51                       ` Andy Lutomirski
     [not found]                         ` <CALCETrUT73CcPQx2T=1zWbOUhw9r-c_YqXw5-KTwxgWPgXuTwA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-22 19:29                           ` Kees Cook
     [not found]                             ` <CAGXu5jLV+WZyj+xnxVFkFEgEthNt6eXdcSgHT-=85mJ1ECZ1Rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-24 14:25                               ` Djalal Harouni
2017-04-24 18:02                                 ` Kees Cook
     [not found]                                   ` <CAGXu5jL_-cxidy_O4ORaN0iX9o7=hsi3DYTRvQs5w5363Z+MVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-24 18:35                                     ` Djalal Harouni
2017-04-21 23:52               ` Casey Schaufler
2017-04-22  0:00                 ` Andy Lutomirski
2017-04-22  0:13                   ` Casey Schaufler
2017-04-22  6:45                     ` Andy Lutomirski
2017-04-22 12:17               ` Djalal Harouni
     [not found]                 ` <CAEiveUdbQcfn1xC5xWMv91vL_uR1MGTvARqw-E4GDTMUZ6t=bA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-04 13:07                   ` Djalal Harouni
2017-05-04 14:58                     ` Serge E. Hallyn
2017-05-05 13:06                       ` Djalal Harouni
2017-05-05 16:18                     ` Andy Lutomirski
2017-04-20  1:57   ` kbuild test robot
     [not found]   ` <1492640420-27345-3-git-send-email-tixxdz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-19 22:38     ` Djalal Harouni
2017-04-24  4:29     ` Rusty Russell
2017-04-26  9:06       ` Djalal Harouni [this message]
2017-04-27  2:07         ` Rusty Russell
     [not found]           ` <87k266hacq.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2017-04-27 13:16             ` Djalal Harouni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEiveUfVyLVrCgjniA+7eutv=OGQ2LwBCx0V7JLiySeJz3c5ZQ@mail.gmail.com' \
    --to=tixxdz@gmail.com \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=casey@schaufler-ca.com \
    --cc=corbet@lwn.net \
    --cc=dpark@posteo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.l.morris@oracle.com \
    --cc=jeyu@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=peterz@infradead.org \
    --cc=rusty@rustcorp.com.au \
    --cc=serge@hallyn.com \
    --cc=zendyani@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).