linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Djalal Harouni <tixxdz@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Jessica Yu <jeyu@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	James Morris <james.l.morris@oracle.com>,
	Paul Moore <paul@paul-moore.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Ingo Molnar <mingo@kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Dongsu Park <dpark@posteo.net>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Zendyani <zendyani@gmail.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Ben Hutchings <ben.hutchings@codethink.co.uk>
Subject: Re: [PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction
Date: Mon, 22 May 2017 15:28:32 -0700	[thread overview]
Message-ID: <CAGXu5jL16KHWoddpT2tdnLrgrGM8vDxmTt=BSELf1Pqfquk3YA@mail.gmail.com> (raw)
In-Reply-To: <1495454226-10027-3-git-send-email-tixxdz@gmail.com>

On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni <tixxdz@gmail.com> wrote:
> [...]
> diff --git a/kernel/module.c b/kernel/module.c
> index 4a3665f..ce7a146 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -282,6 +282,8 @@ module_param(sig_enforce, bool_enable_only, 0644);
>
>  /* Block module loading/unloading? */
>  int modules_disabled = 0;
> +int modules_autoload_mode = MODULES_AUTOLOAD_ALLOWED;
> +const int modules_autoload_max = MODULES_AUTOLOAD_DISABLED;
>  core_param(nomodule, modules_disabled, bint, 0);
>
>  /* Waiting for a module to finish initializing? */
> @@ -4296,6 +4298,46 @@ struct module *__module_text_address(unsigned long addr)
>  }
>  EXPORT_SYMBOL_GPL(__module_text_address);
>
> +/**
> + * may_autoload_module - Determine whether a module auto-load operation
> + * is permitted
> + * @kmod_name: The module name
> + * @allow_cap: if positive, may allow to auto-load the module if this capability
> + * is set
> + *
> + * Determine whether a module auto-load operation is allowed or not. The check
> + * uses the sysctl "modules_autoload_mode" value.
> + *
> + * This allows to have more control on automatic module loading, and align it
> + * with explicit load/unload module operations. The kernel contains several
> + * modules, some of them are not updated often and may contain bugs and
> + * vulnerabilities.
> + *
> + * The "allow_cap" is passed by callers to explicitly note that the module has
> + * the appropriate alias and that the "allow_cap" capability is set. This is
> + * for backward compatibility, the aim is to have a clear picture where:
> + *
> + * 1) Implicit module loading is allowed
> + * 2) Implicit module loading as with the explicit one requires CAP_SYS_MODULE.
> + * 3) Implicit module loading as with the explicit one can be disabled.
> + *
> + * Returns 0 if the module request is allowed or -EPERM if not.
> + */
> +int may_autoload_module(char *kmod_name, int allow_cap)
> +{
> +       if (modules_autoload_mode == MODULES_AUTOLOAD_ALLOWED)
> +               return 0;
> +       else if (modules_autoload_mode == MODULES_AUTOLOAD_PRIVILEGED) {
> +               /* Check CAP_SYS_MODULE then allow_cap if valid */
> +               if (capable(CAP_SYS_MODULE) ||
> +                   (allow_cap > 0 && capable(allow_cap)))

With the allow_cap check already happening in my suggestion for
__request_module(), it's not needed here. (In fact, it's not even
really needed to plumb this into the hook, I don't think?

Regardless, I remain a fan. :)

-Kees

-- 
Kees Cook
Pixel Security

  reply	other threads:[~2017-05-22 22:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 11:57 [PATCH v4 next 0/3] modules: automatic module loading restrictions Djalal Harouni
2017-05-22 11:57 ` [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument Djalal Harouni
2017-05-22 22:20   ` Kees Cook
2017-05-23 10:29     ` Djalal Harouni
2017-05-23 19:19       ` Kees Cook
2017-05-24 14:16         ` Djalal Harouni
2017-05-30 17:59           ` Kees Cook
2017-06-01 14:56             ` Djalal Harouni
2017-06-01 19:10               ` Kees Cook
2017-09-02  6:31                 ` Djalal Harouni
2017-05-22 11:57 ` [PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction Djalal Harouni
2017-05-22 22:28   ` Kees Cook [this message]
2017-05-22 11:57 ` [PATCH v4 next 3/3] modules:capabilities: add a per-task modules auto-load mode Djalal Harouni
2017-05-23 14:18   ` kbuild test robot
2017-05-22 12:08 ` [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions Solar Designer
2017-05-22 13:49   ` Djalal Harouni
2017-05-22 16:43     ` Solar Designer
2017-05-22 19:55       ` Djalal Harouni
2017-05-22 23:07         ` Kees Cook
2017-05-22 23:38           ` Andy Lutomirski
2017-05-22 23:52             ` Kees Cook
2017-05-23 13:02             ` Djalal Harouni
2017-05-23  7:48           ` Solar Designer
2017-05-23 18:36             ` Kees Cook
2017-05-23 19:50               ` Andy Lutomirski
2017-05-24 18:06             ` 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='CAGXu5jL16KHWoddpT2tdnLrgrGM8vDxmTt=BSELf1Pqfquk3YA@mail.gmail.com' \
    --to=keescook@chromium.org \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=casey@schaufler-ca.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dpark@posteo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=james.l.morris@oracle.com \
    --cc=jeyu@redhat.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@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=netdev@vger.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=sds@tycho.nsa.gov \
    --cc=serge@hallyn.com \
    --cc=tixxdz@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --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).