Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 06:49:20PM -0500, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 03:29:01PM -0800, Kees Cook wrote: > > > So in these two cases, if the kernel was built w/o modules, and HDLC > > > and DCCP was built-in, you'd be screwed, then? > > > > Sure, but that's not the common

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 06:49:20PM -0500, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 03:29:01PM -0800, Kees Cook wrote: > > > So in these two cases, if the kernel was built w/o modules, and HDLC > > > and DCCP was built-in, you'd be screwed, then? > > > > Sure, but that's not the common

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

It was suggested that the feature would only be adopted in niches like Android and I pointed out that it's not really relevant to Android. It's a waste of time to try convincing me that it's useful elsewhere. I never said or implied that it wasn't. On Thu, 2017-11-30 at 09:50 +0100, Djalal

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

It was suggested that the feature would only be adopted in niches like Android and I pointed out that it's not really relevant to Android. It's a waste of time to try convincing me that it's useful elsewhere. I never said or implied that it wasn't. On Thu, 2017-11-30 at 09:50 +0100, Djalal

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Thu, Nov 30, 2017 at 3:16 PM, Theodore Ts'o wrote: > On Thu, Nov 30, 2017 at 09:50:27AM +0100, Djalal Harouni wrote: >> In embedded systems we can't maintain a SELinux policy, distro man >> power hardly manage. We have abstracted seccomp etc, but the kernel >> inherited the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Thu, Nov 30, 2017 at 3:16 PM, Theodore Ts'o wrote: > On Thu, Nov 30, 2017 at 09:50:27AM +0100, Djalal Harouni wrote: >> In embedded systems we can't maintain a SELinux policy, distro man >> power hardly manage. We have abstracted seccomp etc, but the kernel >> inherited the difficult multiplex

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Thu, Nov 30, 2017 at 09:50:27AM +0100, Djalal Harouni wrote: > In embedded systems we can't maintain a SELinux policy, distro man > power hardly manage. We have abstracted seccomp etc, but the kernel > inherited the difficult multiplex things, plus all other paths that > trigger this. >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Thu, Nov 30, 2017 at 09:50:27AM +0100, Djalal Harouni wrote: > In embedded systems we can't maintain a SELinux policy, distro man > power hardly manage. We have abstracted seccomp etc, but the kernel > inherited the difficult multiplex things, plus all other paths that > trigger this. >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay wrote: [...] > Lots of potential module attack surface also gets eliminated by default > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > commands, etc. The global seccomp whitelist might be relevant in some

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay wrote: [...] > Lots of potential module attack surface also gets eliminated by default > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > commands, etc. The global seccomp whitelist might be relevant in some > cases too. In

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> And once you disable it by default, and it becomes purely opt-in, that > means that nothing will change for most cases. Some embedded people > that do their own thing (ie Android) might change, but normal > distributions probably won't. > > Yes, Android may be 99% of the users, and yes, the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> And once you disable it by default, and it becomes purely opt-in, that > means that nothing will change for most cases. Some embedded people > that do their own thing (ie Android) might change, but normal > distributions probably won't. > > Yes, Android may be 99% of the users, and yes, the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 4:44 PM, Kees Cook wrote: > >> That mainly leaves the protocol ones we need to look out for, I suspect. > > This is where a lot of the exposure really comes from. socket() > triggers a bunch of stuff, but doesn't have an obvious privilege >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 4:44 PM, Kees Cook wrote: > >> That mainly leaves the protocol ones we need to look out for, I suspect. > > This is where a lot of the exposure really comes from. socket() > triggers a bunch of stuff, but doesn't have an obvious privilege > associated with it... while it

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 2:14 PM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: >> 1) Add request_module_cap(required_cap, module_name_prefix, fmt, fmt_args...) >> >> 2) Convert known

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 2:14 PM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: >> 1) Add request_module_cap(required_cap, module_name_prefix, fmt, fmt_args...) >> >> 2) Convert known privileged-but-not-CAP_SYS_MODULE request_module() >> callers to

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: > > So, what we have now is that the permission verification already > happens at and around the existing request_module() calls. Usually, yes. I liked the "request_module_cap()" interface partly because that made the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: > > So, what we have now is that the permission verification already > happens at and around the existing request_module() calls. Usually, yes. I liked the "request_module_cap()" interface partly because that made the net/core/dev_ioctl.c ones

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 10:46 AM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 10:30 AM, Kees Cook wrote: >> On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds >> wrote: >>> >>> Just thinking about the DCCP

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 10:46 AM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 10:30 AM, Kees Cook wrote: >> On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds >> wrote: >>> >>> Just thinking about the DCCP case, where networking people actually >>> knew it was pretty deprecated and had no real

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 10:46 AM, Linus Torvalds wrote: > > So the module flag is technically easy to add, and it's technically > easy to read at module loading time, but I suspect that it's actually > annoyingly hard to pass the original request_module() capability

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 10:46 AM, Linus Torvalds wrote: > > So the module flag is technically easy to add, and it's technically > easy to read at module loading time, but I suspect that it's actually > annoyingly hard to pass the original request_module() capability > information around to where

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 10:30 AM, Kees Cook wrote: > On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds > wrote: >> >> Just thinking about the DCCP case, where networking people actually >> knew it was pretty deprecated and had no real

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 10:30 AM, Kees Cook wrote: > On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds > wrote: >> >> Just thinking about the DCCP case, where networking people actually >> knew it was pretty deprecated and had no real maintainer, I think one >> thing to look at would be simply a

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook wrote: >> >>> The model that I am a proponent of is to take a softer approach >>> initially: don't forbid module loading (because that breaks

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 4:50 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook wrote: >> >>> The model that I am a proponent of is to take a softer approach >>> initially: don't forbid module loading (because that breaks users), >>> but instead _warn_ about non-root module

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> From: Linus Torvalds <torva...@linux-foundation.org> > Sent: Wed Nov 29 01:17:05 CET 2017 > To: Geo Kozey <geoko...@mailfence.com> > Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load 'netdev-%s' modules > >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> From: Linus Torvalds > Sent: Wed Nov 29 01:17:05 CET 2017 > To: Geo Kozey > Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load 'netdev-%s' modules > > > On Tue, Nov 28, 2017 at 3:51 PM, Linus Torvalds >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> From: Theodore Ts'o <ty...@mit.edu> > Sent: Wed Nov 29 00:49:20 CET 2017 > Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load 'netdev-%s' modules > > OK, but if the goal is to protect users who are running distro

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> From: Theodore Ts'o > Sent: Wed Nov 29 00:49:20 CET 2017 > Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load 'netdev-%s' modules > > OK, but if the goal is to protect users who are running distro > kernels,

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 04:18:59PM -0800, Kees Cook wrote: > There's also a difference between immutable CONFIG options that cannot > be disabled at runtime, those that can, global sysctls, per-namespace > controls, etc etc. The kernel is all about providing admins with knobs > to tweak their

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 04:18:59PM -0800, Kees Cook wrote: > There's also a difference between immutable CONFIG options that cannot > be disabled at runtime, those that can, global sysctls, per-namespace > controls, etc etc. The kernel is all about providing admins with knobs > to tweak their

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

Linus Torvalds writes: > On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook wrote: >> >>> The model that I am a proponent of is to take a softer approach >>> initially: don't forbid module loading (because that breaks users), >>> but instead _warn_

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

Linus Torvalds writes: > On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook wrote: >> >>> The model that I am a proponent of is to take a softer approach >>> initially: don't forbid module loading (because that breaks users), >>> but instead _warn_ about non-root module loading. And then we can >>>

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook wrote: > >> The model that I am a proponent of is to take a softer approach >> initially: don't forbid module loading (because that breaks users), >> but instead _warn_ about non-root module loading. And then we can >> start fixing

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 4:26 PM, Kees Cook wrote: > >> The model that I am a proponent of is to take a softer approach >> initially: don't forbid module loading (because that breaks users), >> but instead _warn_ about non-root module loading. And then we can >> start fixing the cases that we

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 4:17 PM, Linus Torvalds wrote: > But at the same time, if people can't even be bothered to try to > improve the general case, and only do things that you have to opt in > for, it really isn't much of an improvement. We had this whole Right,

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 4:17 PM, Linus Torvalds wrote: > But at the same time, if people can't even be bothered to try to > improve the general case, and only do things that you have to opt in > for, it really isn't much of an improvement. We had this whole Right, and I'm fine to help with those

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 3:49 PM, Theodore Ts'o wrote: > OK, but if the goal is to protect users who are running distro > kernels, then a kernel config that breaks some percentage of users is > highly unlikely to be enabled by Red Hat and SuSE, right? And > many of these

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 3:49 PM, Theodore Ts'o wrote: > OK, but if the goal is to protect users who are running distro > kernels, then a kernel config that breaks some percentage of users is > highly unlikely to be enabled by Red Hat and SuSE, right? And > many of these users either

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 3:51 PM, Linus Torvalds wrote: > > So a patch that avoids breaking existing users, but also doesn't > actually improve anything for existing users, simply shouldn't be part > of the mainline kernel. Just to clarify: maybe it ends up being

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 3:51 PM, Linus Torvalds wrote: > > So a patch that avoids breaking existing users, but also doesn't > actually improve anything for existing users, simply shouldn't be part > of the mainline kernel. Just to clarify: maybe it ends up being truly impossible to make the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The exploit for

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 1:51 PM, Geo Kozey wrote: > > What about "we're insecure by default but you can't do anything to change > this"? It describes current situation. Go away, and don't send me patches until you have dug your head out of whatever hole you have put it

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 1:51 PM, Geo Kozey wrote: > > What about "we're insecure by default but you can't do anything to change > this"? It describes current situation. Go away, and don't send me patches until you have dug your head out of whatever hole you have put it in.. If this is the kind

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 03:29:01PM -0800, Kees Cook wrote: > > So in these two cases, if the kernel was built w/o modules, and HDLC > > and DCCP was built-in, you'd be screwed, then? > > Sure, but that's not the common situation. > > > Is the goal here to protect people using distro kernels

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 03:29:01PM -0800, Kees Cook wrote: > > So in these two cases, if the kernel was built w/o modules, and HDLC > > and DCCP was built-in, you'd be screwed, then? > > Sure, but that's not the common situation. > > > Is the goal here to protect people using distro kernels

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 3:23 PM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 3:23 PM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The exploit for

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: > As I've said before, this isn't a theoretical attack surface. This > year alone there have been three known-exploitable flaws exposed by > autoloading: > > The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd, > TIOCSETD,

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: > As I've said before, this isn't a theoretical attack surface. This > year alone there have been three known-exploitable flaws exposed by > autoloading: > > The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd, > TIOCSETD,

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> From: Linus Torvalds <torva...@linux-foundation.org> > Sent: Tue Nov 28 21:33:22 CET 2017 > To: Kees Cook <keesc...@chromium.org> > Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load 'netdev-%s' mod

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> From: Linus Torvalds > Sent: Tue Nov 28 21:33:22 CET 2017 > To: Kees Cook > Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load 'netdev-%s' modules > Because I really am *not* interested in these security flags that ar

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook 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

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook wrote: >> >> So what's the right path forward for allowing a way to block >> autoloading? Separate existing request_module() calls into "must

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook 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

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook 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

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook 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

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:12 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:08 PM, Kees Cook wrote: >> >> Linus, are you okay with this series if the global sysctl gets dropped? > > So really, it's not the "global sysctl" as much as

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:12 PM, Linus Torvalds wrote: > On Tue, Nov 28, 2017 at 12:08 PM, Kees Cook wrote: >> >> Linus, are you okay with this series if the global sysctl gets dropped? > > So really, it's not the "global sysctl" as much as the "global > request_module()" that annoys me. > >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:08 PM, Kees Cook wrote: > > Linus, are you okay with this series if the global sysctl gets dropped? So really, it's not the "global sysctl" as much as the "global request_module()" that annoys me. I'll happily take the request_module_cap() part

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 12:08 PM, Kees Cook wrote: > > Linus, are you okay with this series if the global sysctl gets dropped? So really, it's not the "global sysctl" as much as the "global request_module()" that annoys me. I'll happily take the request_module_cap() part and the thing that

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 11:32 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:16:59PM +0100, Geo Kozey wrote: >> >> Userspace can be configured in a way which is compatible with those >> changes being on the same as it can be configured to work with >> selinux. That means on

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 11:32 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:16:59PM +0100, Geo Kozey wrote: >> >> Userspace can be configured in a way which is compatible with those >> changes being on the same as it can be configured to work with >> selinux. That means on distro level or

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 01:16:59PM +0100, Geo Kozey wrote: > > Userspace can be configured in a way which is compatible with those > changes being on the same as it can be configured to work with > selinux. That means on distro level or sysadmin level it's a > valuable tool. It's better than

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Tue, Nov 28, 2017 at 01:16:59PM +0100, Geo Kozey wrote: > > Userspace can be configured in a way which is compatible with those > changes being on the same as it can be configured to work with > selinux. That means on distro level or sysadmin level it's a > valuable tool. It's better than

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> Molnar <mi...@kernel.org>, David S. Miller <da...@davemloft.net>, Network > Development <net...@vger.kernel.org>, Peter Zijlstra <pet...@infradead.org> > Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to l

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

ernel Mailing List > , LSM List > , kernel-harden...@lists.openwall.com > , Jonathan Corbet , Ingo > Molnar , David S. Miller , Network > Development , Peter Zijlstra > Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use > request_module_cap() to load