[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Nov 2017 10:44:52 +1100 (AEDT)
From: James Morris <james.l.morris@...cle.com>
To: Kees Cook <keescook@...omium.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>, Djalal Harouni <tixxdz@...il.com>,
Andy Lutomirski <luto@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
Ben Hutchings <ben.hutchings@...ethink.co.uk>,
Solar Designer <solar@...nwall.com>,
"Serge E. Hallyn" <serge@...lyn.com>, Jessica Yu <jeyu@...nel.org>,
Rusty Russell <rusty@...tcorp.com.au>,
LKML <linux-kernel@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
kernel-hardening@...ts.openwall.com, Jonathan Corbet <corbet@....net>,
Ingo Molnar <mingo@...nel.org>,
Network Development <netdev@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure
On Mon, 27 Nov 2017, Kees Cook wrote:
> > if (WARN_ON_ONCE(!capable(CAP_SYS_MODULE) ||
> > !capable(CAP_SYS_ADMIN) ||
> > !capable(CAP_NET_ADMIN) ||
> > !unprivileged_autoload(module_name)))
(Side note: the capable() calls would ideally come after the whitelist
check).
> We have some of this already with the module prefixes. Doing this
> per-module would need to be exported to userspace, I think. It'd be
> way too fragile sitting in the kernel.
What about writing a whitelist to /proc (per-task) or /sys/fs (global) ?
The per-task whitelist is inherited from the global one by default, or
from a parent process if it's been modified in the parent.
--
James Morris
<james.l.morris@...cle.com>
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.
