Date: Mon, 22 May 2017 15:49:15 +0200 From: Djalal Harouni <tixxdz@...il.com> To: Solar Designer <solar@...nwall.com> Cc: linux-kernel <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org, LSM List <linux-security-module@...r.kernel.org>, kernel-hardening@...ts.openwall.com, Andy Lutomirski <luto@...nel.org>, Kees Cook <keescook@...omium.org>, Andrew Morton <akpm@...ux-foundation.org>, Rusty Russell <rusty@...tcorp.com.au>, "Serge E. Hallyn" <serge@...lyn.com>, Jessica Yu <jeyu@...hat.com>, "David S. Miller" <davem@...emloft.net>, James Morris <james.l.morris@...cle.com>, Paul Moore <paul@...l-moore.com>, Stephen Smalley <sds@...ho.nsa.gov>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, Ingo Molnar <mingo@...nel.org>, Linux API <linux-api@...r.kernel.org>, Dongsu Park <dpark@...teo.net>, Casey Schaufler <casey@...aufler-ca.com>, Jonathan Corbet <corbet@....net>, Arnaldo Carvalho de Melo <acme@...hat.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Zendyani <zendyani@...il.com>, "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, Al Viro <viro@...iv.linux.org.uk>, Ben Hutchings <ben.hutchings@...ethink.co.uk> Subject: Re: [PATCH v4 next 0/3] modules: automatic module loading restrictions Hi Alexander, On Mon, May 22, 2017 at 2:08 PM, Solar Designer <solar@...nwall.com> wrote: > Hi Djalal, > > Thank you for your work on this! > > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: >> *) When modules_autoload_mode is set to (2), automatic module loading is >> disabled for all. Once set, this value can not be changed. > > What purpose does this securelevel-like property ("Once set, this value > can not be changed.") serve here? I think this mode 2 is needed, but > without this extra property, which is bypassable by e.g. explicitly > loaded kernel modules anyway (and that's OK). My reasoning about "Once set, this value can not be changed" is mainly for: If you have some systems where modules are not updated for any given reason, then the only one who will be able to load a module is an administrator, basically this is a shortcut for: * Apps/services can run with CAP_NET_ADMIN but they are not allowed to auto-load 'netdev' modules. * Explicitly loading modules can be guarded by seccomp filters *per* app, so even if these apps have CAP_SYS_MODULE they won't be able to explicitly load modules, one has to remount some sysctl /proc/ entries read-only here and remove CAP_SYS_ADMIN for all apps anyway. This mainly serves the purpose of these systems that do not receive updates, if I don't want to expose those kernel interfaces what should I do ? then if I want to unload old versions and replace them with new ones what operation should be allowed ? and only real root of the system can do it. Hence, the "Once set, this value can not be changed" is more of a shortcut, also the idea was put in my mind based on how "modules_disabled" is disabled forever, and some other interfaces. I would say: it is easy to handle a transition from 1) "hey this system is still up to date, some features should be exposed" to 2) "this system is not up to date anymore, only root should expose some features..." Hmm, I am not sure if this answers your question ? :-) I definitively don't want to fall into "modules_disabled" trap where is it too strict! "Once set, this value can not be changed" means for some users do not set it otherwise the system is unusable... Maybe an extra "4" mode for that ? better get it right. Thanks! -- 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.