From: Djalal Harouni <tixxdz@gmail.com> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org>, "Theodore Ts'o" <tytso@mit.edu>, Jonathan Corbet <corbet@lwn.net>, James Morris <james.l.morris@oracle.com>, LSM List <linux-security-module@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com>, Geo Kozey <geokozey@mailfence.com> Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules Date: Tue, 28 Nov 2017 22:10:24 +0100 [thread overview] Message-ID: <CAEiveUehNyZ3mFwzvuu1fj87_37QR+rRyQ9pBLzj-V6yshP1-g@mail.gmail.com> (raw) In-Reply-To: <CA+55aFz0t7cCkePJQ1w44Kw_g5nns1tYJLUOL7f-c7vriqkFig@mail.gmail.com> On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook <keescook@chromium.org> wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into "must be >> privileged" and "can be unpriv" first, then rework the series to deal >> with the "unpriv okay" subset? > > So once we've taken care of the networking ones that check their own > different capability bit, maybe we can then make the regular > request_module() do a rate-limited warning for non-CAP_SYS_MODULE uses > that prints which module it's loading. Alright, I can start by those. > And then just see what people report. > > Because maybe it's just a very small handful that matters, and we can > say "those are ok". The ones that are in the cover letter, etc may not have the appropriate context, the request_module_dev() sure can be made since if you can open you already have the context. > And maybe that is too optimistic, and we have a lot of device driver > ones because people still have a static /dev and don't have udev > populating modules and device nodes, and then maybe we need to > introduce a "request_module_dev()" where the rule is that you had to > at least have privileges to open the device node. > > Because I really am *not* interested in these security flags that are > off by default and then get turned on by special cases. I think it's > completely unacceptable to say "we're insecure by default but then you > can do X and be secure". It doesn't work. It doesn't fix anything. this still leaves all the cases where we don't have the appropriate context and other implicit loads that are triggered by another implicit load, etc. Also the simple local flag is easy to grasp, with real users for it, and we can abstract on top with load "newfeatures" of course this does not mean that we should say "we-re insecure by default". I want it to be more allow newfeatures or not for apps and users... requiring caps may give users the idea to pass CAP_SYS_MODULE or other caps for something that used to work, they may start giving it if we break lot of usecases, and yeh the caps are much broader and do much more harm... Ok, so beside updating with request_module_cap() I will investigate request_module_dev() and we can see Thanks! > Linus -- tixxdz
WARNING: multiple messages have this Message-ID (diff)
From: tixxdz@gmail.com (Djalal Harouni) To: linux-security-module@vger.kernel.org Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules Date: Tue, 28 Nov 2017 22:10:24 +0100 [thread overview] Message-ID: <CAEiveUehNyZ3mFwzvuu1fj87_37QR+rRyQ9pBLzj-V6yshP1-g@mail.gmail.com> (raw) In-Reply-To: <CA+55aFz0t7cCkePJQ1w44Kw_g5nns1tYJLUOL7f-c7vriqkFig@mail.gmail.com> On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook <keescook@chromium.org> wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into "must be >> privileged" and "can be unpriv" first, then rework the series to deal >> with the "unpriv okay" subset? > > So once we've taken care of the networking ones that check their own > different capability bit, maybe we can then make the regular > request_module() do a rate-limited warning for non-CAP_SYS_MODULE uses > that prints which module it's loading. Alright, I can start by those. > And then just see what people report. > > Because maybe it's just a very small handful that matters, and we can > say "those are ok". The ones that are in the cover letter, etc may not have the appropriate context, the request_module_dev() sure can be made since if you can open you already have the context. > And maybe that is too optimistic, and we have a lot of device driver > ones because people still have a static /dev and don't have udev > populating modules and device nodes, and then maybe we need to > introduce a "request_module_dev()" where the rule is that you had to > at least have privileges to open the device node. > > Because I really am *not* interested in these security flags that are > off by default and then get turned on by special cases. I think it's > completely unacceptable to say "we're insecure by default but then you > can do X and be secure". It doesn't work. It doesn't fix anything. this still leaves all the cases where we don't have the appropriate context and other implicit loads that are triggered by another implicit load, etc. Also the simple local flag is easy to grasp, with real users for it, and we can abstract on top with load "newfeatures" of course this does not mean that we should say "we-re insecure by default". I want it to be more allow newfeatures or not for apps and users... requiring caps may give users the idea to pass CAP_SYS_MODULE or other caps for something that used to work, they may start giving it if we break lot of usecases, and yeh the caps are much broader and do much more harm... Ok, so beside updating with request_module_cap() I will investigate request_module_dev() and we can see Thanks! > Linus -- tixxdz -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-11-28 21:10 UTC|newest] Thread overview: 266+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-27 17:18 [PATCH v5 next 0/5] Improve Module autoloading infrastructure Djalal Harouni 2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni 2017-11-27 17:18 ` Djalal Harouni 2017-11-27 17:18 ` [PATCH v5 next 1/5] modules:capabilities: add request_module_cap() Djalal Harouni 2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni 2017-11-27 17:18 ` Djalal Harouni 2017-11-27 18:48 ` Randy Dunlap 2017-11-27 18:48 ` [kernel-hardening] " Randy Dunlap 2017-11-27 18:48 ` Randy Dunlap 2017-11-27 21:35 ` Djalal Harouni 2017-11-27 21:35 ` [kernel-hardening] " Djalal Harouni 2017-11-27 21:35 ` Djalal Harouni 2017-11-28 19:14 ` Luis R. Rodriguez 2017-11-28 19:14 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-28 19:14 ` Luis R. Rodriguez 2017-11-28 20:11 ` Kees Cook 2017-11-28 20:11 ` [kernel-hardening] " Kees Cook 2017-11-28 20:11 ` Kees Cook 2017-11-28 21:16 ` Luis R. Rodriguez 2017-11-28 21:16 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-28 21:16 ` Luis R. Rodriguez 2017-11-28 21:33 ` Djalal Harouni 2017-11-28 21:33 ` [kernel-hardening] " Djalal Harouni 2017-11-28 21:33 ` Djalal Harouni 2017-11-28 22:18 ` Luis R. Rodriguez 2017-11-28 22:18 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-28 22:18 ` Luis R. Rodriguez 2017-11-28 22:52 ` Djalal Harouni 2017-11-28 22:52 ` [kernel-hardening] " Djalal Harouni 2017-11-28 22:52 ` Djalal Harouni 2017-11-28 21:39 ` Kees Cook 2017-11-28 21:39 ` [kernel-hardening] " Kees Cook 2017-11-28 21:39 ` Kees Cook 2017-11-28 22:12 ` Luis R. Rodriguez 2017-11-28 22:12 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-28 22:12 ` Luis R. Rodriguez 2017-11-28 22:18 ` Kees Cook 2017-11-28 22:18 ` [kernel-hardening] " Kees Cook 2017-11-28 22:18 ` Kees Cook 2017-11-28 22:48 ` Luis R. Rodriguez 2017-11-28 22:48 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-28 22:48 ` Luis R. Rodriguez 2017-11-29 7:49 ` Michal Kubecek 2017-11-29 7:49 ` [kernel-hardening] " Michal Kubecek 2017-11-29 7:49 ` Michal Kubecek 2017-11-29 13:46 ` Alan Cox 2017-11-29 13:46 ` [kernel-hardening] " Alan Cox 2017-11-29 13:46 ` Alan Cox 2017-11-29 14:50 ` David Miller 2017-11-29 14:50 ` [kernel-hardening] " David Miller 2017-11-29 14:50 ` David Miller 2017-11-29 15:54 ` Theodore Ts'o 2017-11-29 15:54 ` [kernel-hardening] " Theodore Ts'o 2017-11-29 15:54 ` Theodore Ts'o 2017-11-29 15:58 ` David Miller 2017-11-29 15:58 ` [kernel-hardening] " David Miller 2017-11-29 15:58 ` David Miller 2017-11-29 16:29 ` Theodore Ts'o 2017-11-29 16:29 ` [kernel-hardening] " Theodore Ts'o 2017-11-29 16:29 ` Theodore Ts'o 2017-11-29 22:45 ` Linus Torvalds 2017-11-29 22:45 ` [kernel-hardening] " Linus Torvalds 2017-11-29 22:45 ` Linus Torvalds 2017-11-29 22:45 ` Linus Torvalds 2017-11-30 0:06 ` Kees Cook 2017-11-30 0:06 ` [kernel-hardening] " Kees Cook 2017-11-30 0:06 ` Kees Cook 2017-11-30 0:06 ` Kees Cook 2017-11-29 17:28 ` Serge E. Hallyn 2017-11-29 17:28 ` [kernel-hardening] " Serge E. Hallyn 2017-11-29 17:28 ` Serge E. Hallyn 2017-11-30 0:35 ` Theodore Ts'o 2017-11-30 0:35 ` [kernel-hardening] " Theodore Ts'o 2017-11-30 0:35 ` Theodore Ts'o 2017-11-30 17:17 ` Serge E. Hallyn 2017-11-30 17:17 ` [kernel-hardening] " Serge E. Hallyn 2017-11-30 17:17 ` Serge E. Hallyn 2017-11-28 20:18 ` Djalal Harouni 2017-11-28 20:18 ` [kernel-hardening] " Djalal Harouni 2017-11-28 20:18 ` Djalal Harouni 2017-11-27 17:18 ` [PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check Djalal Harouni 2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni 2017-11-27 17:18 ` Djalal Harouni 2017-11-30 2:05 ` Luis R. Rodriguez 2017-11-30 2:05 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-30 2:05 ` Luis R. Rodriguez 2017-11-27 17:18 ` [PATCH v5 next 3/5] modules:capabilities: automatic module loading restriction Djalal Harouni 2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni 2017-11-27 17:18 ` Djalal Harouni 2017-11-30 1:23 ` Luis R. Rodriguez 2017-11-30 1:23 ` [kernel-hardening] " Luis R. Rodriguez 2017-11-30 1:23 ` Luis R. Rodriguez 2017-11-30 12:22 ` Djalal Harouni 2017-11-30 12:22 ` [kernel-hardening] " Djalal Harouni 2017-11-30 12:22 ` Djalal Harouni 2017-11-27 17:18 ` [PATCH v5 next 4/5] modules:capabilities: add a per-task modules auto-load mode Djalal Harouni 2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni 2017-11-27 17:18 ` Djalal Harouni 2017-11-27 17:18 ` [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules Djalal Harouni 2017-11-27 17:18 ` [kernel-hardening] " Djalal Harouni 2017-11-27 17:18 ` Djalal Harouni 2017-11-27 18:44 ` Linus Torvalds 2017-11-27 18:44 ` [kernel-hardening] " Linus Torvalds 2017-11-27 18:44 ` Linus Torvalds 2017-11-27 18:44 ` Linus Torvalds 2017-11-27 21:41 ` Djalal Harouni 2017-11-27 21:41 ` [kernel-hardening] " Djalal Harouni 2017-11-27 21:41 ` Djalal Harouni 2017-11-27 21:41 ` Djalal Harouni 2017-11-27 22:04 ` Linus Torvalds 2017-11-27 22:04 ` [kernel-hardening] " Linus Torvalds 2017-11-27 22:04 ` Linus Torvalds 2017-11-27 22:04 ` Linus Torvalds 2017-11-27 22:59 ` Kees Cook 2017-11-27 22:59 ` [kernel-hardening] " Kees Cook 2017-11-27 22:59 ` Kees Cook 2017-11-27 22:59 ` Kees Cook 2017-11-27 23:14 ` Linus Torvalds 2017-11-27 23:14 ` [kernel-hardening] " Linus Torvalds 2017-11-27 23:14 ` Linus Torvalds 2017-11-27 23:14 ` Linus Torvalds 2017-11-27 23:19 ` Kees Cook 2017-11-27 23:19 ` [kernel-hardening] " Kees Cook 2017-11-27 23:19 ` Kees Cook 2017-11-27 23:19 ` Kees Cook 2017-11-27 23:35 ` Linus Torvalds 2017-11-27 23:35 ` [kernel-hardening] " Linus Torvalds 2017-11-27 23:35 ` Linus Torvalds 2017-11-27 23:35 ` Linus Torvalds 2017-11-28 1:23 ` Kees Cook 2017-11-28 1:23 ` [kernel-hardening] " Kees Cook 2017-11-28 1:23 ` Kees Cook 2017-11-28 1:23 ` Kees Cook 2017-11-28 12:16 ` [kernel-hardening] " Geo Kozey 2017-11-28 12:16 ` Geo Kozey 2017-11-28 12:16 ` Geo Kozey 2017-11-28 19:32 ` Theodore Ts'o 2017-11-28 19:32 ` Theodore Ts'o 2017-11-28 19:32 ` Theodore Ts'o 2017-11-28 20:08 ` Kees Cook 2017-11-28 20:08 ` Kees Cook 2017-11-28 20:08 ` Kees Cook 2017-11-28 20:12 ` Linus Torvalds 2017-11-28 20:12 ` Linus Torvalds 2017-11-28 20:12 ` Linus Torvalds 2017-11-28 20:20 ` Kees Cook 2017-11-28 20:20 ` Kees Cook 2017-11-28 20:20 ` Kees Cook 2017-11-28 20:33 ` Linus Torvalds 2017-11-28 20:33 ` Linus Torvalds 2017-11-28 20:33 ` Linus Torvalds 2017-11-28 21:10 ` Djalal Harouni [this message] 2017-11-28 21:10 ` Djalal Harouni 2017-11-28 21:10 ` Djalal Harouni 2017-11-28 21:33 ` Kees Cook 2017-11-28 21:33 ` Kees Cook 2017-11-28 21:33 ` Kees Cook 2017-11-28 23:23 ` Theodore Ts'o 2017-11-28 23:23 ` Theodore Ts'o 2017-11-28 23:23 ` Theodore Ts'o 2017-11-28 23:29 ` Kees Cook 2017-11-28 23:29 ` Kees Cook 2017-11-28 23:29 ` Kees Cook 2017-11-28 23:49 ` Theodore Ts'o 2017-11-28 23:49 ` Theodore Ts'o 2017-11-28 23:49 ` Theodore Ts'o 2017-11-29 0:18 ` Kees Cook 2017-11-29 0:18 ` Kees Cook 2017-11-29 0:18 ` Kees Cook 2017-11-29 6:36 ` Theodore Ts'o 2017-11-29 6:36 ` Theodore Ts'o 2017-11-29 6:36 ` Theodore Ts'o 2017-11-29 14:46 ` Geo Kozey 2017-11-29 14:46 ` Geo Kozey 2017-11-29 14:46 ` Geo Kozey 2017-12-01 15:22 ` Marcus Meissner 2017-12-01 15:22 ` Marcus Meissner 2017-12-01 15:22 ` Marcus Meissner 2017-11-28 23:53 ` Djalal Harouni 2017-11-28 23:53 ` Djalal Harouni 2017-11-28 23:53 ` Djalal Harouni 2017-11-28 21:51 ` Geo Kozey 2017-11-28 21:51 ` Geo Kozey 2017-11-28 21:51 ` Geo Kozey 2017-11-28 23:51 ` Linus Torvalds 2017-11-28 23:51 ` Linus Torvalds 2017-11-28 23:51 ` Linus Torvalds 2017-11-29 0:17 ` Linus Torvalds 2017-11-29 0:17 ` Linus Torvalds 2017-11-29 0:17 ` Linus Torvalds 2017-11-29 0:26 ` Kees Cook 2017-11-29 0:26 ` Kees Cook 2017-11-29 0:26 ` Kees Cook 2017-11-29 0:50 ` Linus Torvalds 2017-11-29 0:50 ` Linus Torvalds 2017-11-29 0:50 ` Linus Torvalds 2017-11-29 4:26 ` Eric W. Biederman 2017-11-29 4:26 ` Eric W. Biederman 2017-11-29 4:26 ` Eric W. Biederman 2017-11-29 18:30 ` Kees Cook 2017-11-29 18:30 ` Kees Cook 2017-11-29 18:30 ` Kees Cook 2017-11-29 18:46 ` Linus Torvalds 2017-11-29 18:46 ` Linus Torvalds 2017-11-29 18:46 ` Linus Torvalds 2017-11-29 18:53 ` Linus Torvalds 2017-11-29 18:53 ` Linus Torvalds 2017-11-29 18:53 ` Linus Torvalds 2017-11-29 21:17 ` Kees Cook 2017-11-29 21:17 ` Kees Cook 2017-11-29 21:17 ` Kees Cook 2017-11-29 22:14 ` Linus Torvalds 2017-11-29 22:14 ` Linus Torvalds 2017-11-29 22:14 ` Linus Torvalds 2017-11-30 0:44 ` Kees Cook 2017-11-30 0:44 ` Kees Cook 2017-11-30 0:44 ` Kees Cook 2017-11-30 2:08 ` Linus Torvalds 2017-11-30 2:08 ` Linus Torvalds 2017-11-30 2:08 ` Linus Torvalds 2017-11-30 6:51 ` Daniel Micay 2017-11-30 6:51 ` Daniel Micay 2017-11-30 6:51 ` Daniel Micay 2017-11-30 8:50 ` Djalal Harouni 2017-11-30 8:50 ` Djalal Harouni 2017-11-30 8:50 ` Djalal Harouni 2017-11-30 14:16 ` Theodore Ts'o 2017-11-30 14:16 ` Theodore Ts'o 2017-11-30 14:16 ` Theodore Ts'o 2017-11-30 14:51 ` Djalal Harouni 2017-11-30 14:51 ` Djalal Harouni 2017-11-30 14:51 ` Djalal Harouni 2017-12-01 6:39 ` Daniel Micay 2017-12-01 6:39 ` Daniel Micay 2017-12-01 6:39 ` Daniel Micay 2017-11-29 15:28 ` Geo Kozey 2017-11-29 15:28 ` Geo Kozey 2017-11-29 15:28 ` Geo Kozey 2017-11-27 18:41 ` [PATCH v5 next 0/5] Improve Module autoloading infrastructure Linus Torvalds 2017-11-27 18:41 ` [kernel-hardening] " Linus Torvalds 2017-11-27 18:41 ` Linus Torvalds 2017-11-27 18:41 ` Linus Torvalds 2017-11-27 19:02 ` Linus Torvalds 2017-11-27 19:02 ` [kernel-hardening] " Linus Torvalds 2017-11-27 19:02 ` Linus Torvalds 2017-11-27 19:02 ` Linus Torvalds 2017-11-27 19:12 ` Linus Torvalds 2017-11-27 19:12 ` [kernel-hardening] " Linus Torvalds 2017-11-27 19:12 ` Linus Torvalds 2017-11-27 19:12 ` Linus Torvalds 2017-11-27 21:31 ` Djalal Harouni 2017-11-27 21:31 ` [kernel-hardening] " Djalal Harouni 2017-11-27 21:31 ` Djalal Harouni 2017-11-27 21:31 ` Djalal Harouni 2017-11-27 19:14 ` David Miller 2017-11-27 19:14 ` [kernel-hardening] " David Miller 2017-11-27 19:14 ` David Miller 2017-11-27 22:31 ` James Morris 2017-11-27 22:31 ` [kernel-hardening] " James Morris 2017-11-27 22:31 ` James Morris 2017-11-27 23:04 ` Kees Cook 2017-11-27 23:04 ` [kernel-hardening] " Kees Cook 2017-11-27 23:04 ` Kees Cook 2017-11-27 23:44 ` James Morris 2017-11-27 23:44 ` [kernel-hardening] " James Morris 2017-11-27 23:44 ` James Morris
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=CAEiveUehNyZ3mFwzvuu1fj87_37QR+rRyQ9pBLzj-V6yshP1-g@mail.gmail.com \ --to=tixxdz@gmail.com \ --cc=corbet@lwn.net \ --cc=geokozey@mailfence.com \ --cc=james.l.morris@oracle.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=tytso@mit.edu \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.