Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc mounts when not fully visible

On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman wrote: [...] > > The only option I have seen proposed that might qualify as something > general purpose and simple is a new filesystem that is just the process > directories of proc. As there would in essence be no files

Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc mounts when not fully visible

On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman wrote: [...] > > The only option I have seen proposed that might qualify as something > general purpose and simple is a new filesystem that is just the process > directories of proc. As there would in essence be no files that would > need

Re: module: add debugging alias parsing support

On Mon, Dec 4, 2017 at 2:58 PM, Jessica Yu <j...@kernel.org> wrote: > +++ Djalal Harouni [04/12/17 10:01 +0100]: >> >> On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez <mcg...@kernel.org> >> wrote: >>> >>> On Thu, Nov 30, 2017 at 02:17:11PM

Re: module: add debugging alias parsing support

On Mon, Dec 4, 2017 at 2:58 PM, Jessica Yu wrote: > +++ Djalal Harouni [04/12/17 10:01 +0100]: >> >> On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez >> wrote: >>> >>> On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote: >>>> >>

Re: module: add debugging alias parsing support

On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez wrote: > On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote: >> Just some quick questions - are there any plans to use these in-kernel >> module aliases anywhere else? Or are you using them just for debugging? > > As-is

Re: module: add debugging alias parsing support

On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez wrote: > On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote: >> Just some quick questions - are there any plans to use these in-kernel >> module aliases anywhere else? Or are you using them just for debugging? > > As-is for now just

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 <ty...@mit.edu> 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 th

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 th

Re: [PATCH v5 next 3/5] modules:capabilities: automatic module loading restriction

On Thu, Nov 30, 2017 at 2:23 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Mon, Nov 27, 2017 at 06:18:36PM +0100, Djalal Harouni wrote: >> diff --git a/include/linux/module.h b/include/linux/module.h >> index 5cbb239..c36aed8 100644 >> --- a/include/linux/modu

Re: [PATCH v5 next 3/5] modules:capabilities: automatic module loading restriction

On Thu, Nov 30, 2017 at 2:23 AM, Luis R. Rodriguez wrote: > On Mon, Nov 27, 2017 at 06:18:36PM +0100, Djalal Harouni wrote: >> diff --git a/include/linux/module.h b/include/linux/module.h >> index 5cbb239..c36aed8 100644 >> --- a/include/linux/module.h >> +++ b/include/

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

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: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Tue, Nov 28, 2017 at 11:18 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Tue, Nov 28, 2017 at 10:33:27PM +0100, Djalal Harouni wrote: >> On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez <mcg...@kernel.org> >> wrote: >> > On Tue, Nov 28, 2017

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Tue, Nov 28, 2017 at 11:18 PM, Luis R. Rodriguez wrote: > On Tue, Nov 28, 2017 at 10:33:27PM +0100, Djalal Harouni wrote: >> On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez >> wrote: >> > On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote: >> >&

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez wrote: > On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote: >> On Tue, Nov 28, 2017 at 11:14 AM, Luis R. Rodriguez >> wrote: >> > kmod is just a helper to poke userpsace to load a module, that's

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez wrote: > On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote: >> On Tue, Nov 28, 2017 at 11:14 AM, Luis R. Rodriguez >> wrote: >> > kmod is just a helper to poke userpsace to load a module, that's it. >> > >> > The old init_module() and

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: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

Hi Luis, On Tue, Nov 28, 2017 at 8:14 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote: > ... > >> After a discussion with Rusty Russell [1], the suggestion was to pass >> the cap

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

Hi Luis, On Tue, Nov 28, 2017 at 8:14 PM, Luis R. Rodriguez wrote: > On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote: > ... > >> After a discussion with Rusty Russell [1], the suggestion was to pass >> the capability from request_module() to security_

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

Hi Linus, On Mon, Nov 27, 2017 at 7:44 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni <tix...@gmail.com> wrote: >> This uses the new request_module_cap() facility to directly propagate >> CAP_NET_ADMIN capabil

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

Hi Linus, On Mon, Nov 27, 2017 at 7:44 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote: >> This uses the new request_module_cap() facility to directly propagate >> CAP_NET_ADMIN capability and the 'netdev' module prefix to the >>

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

Hi Randy, On Mon, Nov 27, 2017 at 7:48 PM, Randy Dunlap <rdun...@infradead.org> wrote: > Hi, > > Mostly typos/spellos... > > > On 11/27/2017 09:18 AM, Djalal Harouni wrote: >> Cc: Serge Hallyn <se...@hallyn.com> >> Cc: Andy Lutomirski <l...@k

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

Hi Randy, On Mon, Nov 27, 2017 at 7:48 PM, Randy Dunlap wrote: > Hi, > > Mostly typos/spellos... > > > On 11/27/2017 09:18 AM, Djalal Harouni wrote: >> Cc: Serge Hallyn >> Cc: Andy Lutomirski >> Suggested-by: Rusty Russell >> Suggested-by: K

Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure

Hi Linus, On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds > wrote: >> >> Now, the above will not necessarily work with a legacy /dev/ directory >> where al the nodes have been

Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure

Hi Linus, On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds > wrote: >> >> Now, the above will not necessarily work with a legacy /dev/ directory >> where al the nodes have been pre-populated, and opening the device >> node is supposed to

[PATCH v5 next 3/5] modules:capabilities: automatic module loading restriction

hub.io/2017/03/24/CVE-2017-2636.html Cc: Rusty Russell <ru...@rustcorp.com.au> Cc: James Morris <james.l.mor...@oracle.com> Cc: Serge Hallyn <se...@hallyn.com> Cc: Ben Hutchings <ben.hutchi...@codethink.co.uk> Cc: Solar Designer <so...@openwall.com> Cc: Andy Lutomirski <l...@kernel.o

[PATCH v5 next 3/5] modules:capabilities: automatic module loading restriction

rever. [1] http://www.openwall.com/lists/oss-security/2017/02/22/3 [2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074 [3] http://www.openwall.com/lists/oss-security/2017/03/29/2 [4] http://www.openwall.com/lists/oss-security/2017/03/07/6 [5] https://a13xp0p0v.github.io/2017/03/24

[PATCH v5 next 4/5] modules:capabilities: add a per-task modules auto-load mode

ty/2017/02/22/3 [2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074 [3] http://www.openwall.com/lists/oss-security/2017/03/29/2 [4] http://www.openwall.com/lists/oss-security/2017/03/07/6 [5] https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html Cc: Ben Hutchings <be

[PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

[1] https://lkml.org/lkml/2017/4/26/735 [2] https://lkml.org/lkml/2017/5/23/775 Cc: Serge Hallyn <se...@hallyn.com> Cc: Andy Lutomirski <l...@kernel.org> Suggested-by: Rusty Russell <ru...@rustcorp.com.au> Suggested-by: Kees Cook <keesc...@chromium.org>

[PATCH v5 next 4/5] modules:capabilities: add a per-task modules auto-load mode

ity/2017/02/22/3 [2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074 [3] http://www.openwall.com/lists/oss-security/2017/03/29/2 [4] http://www.openwall.com/lists/oss-security/2017/03/07/6 [5] https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html Cc: Ben Hutchings Cc: Rusty R

[PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

[1] https://lkml.org/lkml/2017/4/26/735 [2] https://lkml.org/lkml/2017/5/23/775 Cc: Serge Hallyn Cc: Andy Lutomirski Suggested-by: Rusty Russell Suggested-by: Kees Cook Signed-off-by: Djalal Harouni --- include/linux/kmod.h | 65 ++- include/

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

uggested-by: Rusty Russell <ru...@rustcorp.com.au> Suggested-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- net/core/dev_ioctl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/core/dev_ioctl.c b/net/core/dev

[PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check

patch. Cc: James Morris <james.l.mor...@oracle.com> Cc: Serge Hallyn <se...@hallyn.com> Cc: Andy Lutomirski <l...@kernel.org> Cc: Ben Hutchings <ben.hutchi...@codethink.co.uk> Suggested-by: Rusty Russell <ru...@rustcorp.com.au> Suggested-by: Kees Cook <keesc...@ch

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

and Kees Cook [1] [1] https://lkml.org/lkml/2017/4/26/735 Cc: Ben Hutchings Cc: James Morris Cc: Serge Hallyn Cc: Solar Designer Cc: Andy Lutomirski Suggested-by: Rusty Russell Suggested-by: Kees Cook Signed-off-by: Djalal Harouni --- net/core/dev_ioctl.c | 4 +++- 1 file changed, 3

[PATCH v5 next 2/5] modules:capabilities: add cap_kernel_module_request() permission check

patch. Cc: James Morris Cc: Serge Hallyn Cc: Andy Lutomirski Cc: Ben Hutchings Suggested-by: Rusty Russell Suggested-by: Kees Cook Signed-off-by: Djalal Harouni --- include/linux/module.h | 10 ++ include/linux/security.h | 4 +++- kernel/module.c | 23

[PATCH v5 next 0/5] Improve Module autoloading infrastructure

amed sysctl to "modules_autoload" to align with "modules_disabled" Suggested-by: Kees Cook <keesc...@chromium.org> *) Improved documentation. *) Removed unused code. # Changes since v1: *) Renamed module to ModAutoRestrict *) Improved documentation to explicity refer to

[PATCH v5 next 0/5] Improve Module autoloading infrastructure

) Renamed module to ModAutoRestrict *) Improved documentation to explicity refer to module autoloading. *) Switched to use the new task_security_alloc() hook. *) Switched from rhash tables to use task->security since it is in linux-security/next branch now. *) Check all parameters passed to prctl() sys

Re: [PATCH RFC v3 2/7] proc: move /proc/{self|thread-self} dentries to proc_fs_info

On Fri, Nov 10, 2017 at 11:31 AM, Alexey Dobriyan <adobri...@gmail.com> wrote: > On 11/9/17, Djalal Harouni <tix...@gmail.com> wrote: > >> struct proc_fs_info { >> struct pid_namespace *pid_ns; >> + struct dentry *proc_self; /* For /proc/self/ */ >

Re: [PATCH RFC v3 2/7] proc: move /proc/{self|thread-self} dentries to proc_fs_info

On Fri, Nov 10, 2017 at 11:31 AM, Alexey Dobriyan wrote: > On 11/9/17, Djalal Harouni wrote: > >> struct proc_fs_info { >> struct pid_namespace *pid_ns; >> + struct dentry *proc_self; /* For /proc/self/ */ >> + struct dentry *proc_thread_

Re: [PATCH RFC v3 3/7] proc: add helpers to set and get proc hidepid and gid mount options

On Fri, Nov 10, 2017 at 11:36 AM, Alexey Dobriyan <adobri...@gmail.com> wrote: > On 11/9/17, Djalal Harouni <tix...@gmail.com> wrote: >> --- a/fs/proc/base.c >> +++ b/fs/proc/base.c > >> -static bool has_pid_permissions(struct pid_namespace *pid, >&g

Re: [PATCH RFC v3 3/7] proc: add helpers to set and get proc hidepid and gid mount options

On Fri, Nov 10, 2017 at 11:36 AM, Alexey Dobriyan wrote: > On 11/9/17, Djalal Harouni wrote: >> --- a/fs/proc/base.c >> +++ b/fs/proc/base.c > >> -static bool has_pid_permissions(struct pid_namespace *pid, >> +static bool has_pid_permissions(struct proc_fs_

Re: [PATCH RFC v3 6/7] proc: support new 'pids=all|ptraceable' mount option

On Fri, Nov 10, 2017 at 3:38 AM, Andy Lutomirski <l...@kernel.org> wrote: > On Thu, Nov 9, 2017 at 8:14 AM, Djalal Harouni <tix...@gmail.com> wrote: >> This patch introduces the new 'pids' mount option, as it was discussed >> and suggested by Andy Lutomirski [1]. &

Re: [PATCH RFC v3 6/7] proc: support new 'pids=all|ptraceable' mount option

On Fri, Nov 10, 2017 at 3:38 AM, Andy Lutomirski wrote: > On Thu, Nov 9, 2017 at 8:14 AM, Djalal Harouni wrote: >> This patch introduces the new 'pids' mount option, as it was discussed >> and suggested by Andy Lutomirski [1]. >> >> * If 'pids=' is passed withou

Re: [PATCH RFC v3 4/7] proc: support mounting private procfs instances inside same pid namespace

On Fri, Nov 10, 2017 at 3:53 AM, James Morris <james.l.mor...@oracle.com> wrote: > On Thu, 9 Nov 2017, Djalal Harouni wrote: > >> This should allow later after real testing to have a smooth transition >> to a procfs with default private instances. >> >> [1]

Re: [PATCH RFC v3 4/7] proc: support mounting private procfs instances inside same pid namespace

On Fri, Nov 10, 2017 at 3:53 AM, James Morris wrote: > On Thu, 9 Nov 2017, Djalal Harouni wrote: > >> This should allow later after real testing to have a smooth transition >> to a procfs with default private instances. >> >> [1] >> https://lists.linuxfoun

Re: [PATCH RFC v3 1/7] proc: add proc_fs_info struct to store proc information

On Fri, Nov 10, 2017 at 11:26 AM, Alexey Dobriyan <adobri...@gmail.com> wrote: > On 11/9/17, Djalal Harouni <tix...@gmail.com> wrote: > >> +struct proc_fs_info { >> + struct pid_namespace *pid_ns; >> +}; > >> +static inline struct

Re: [PATCH RFC v3 1/7] proc: add proc_fs_info struct to store proc information

On Fri, Nov 10, 2017 at 11:26 AM, Alexey Dobriyan wrote: > On 11/9/17, Djalal Harouni wrote: > >> +struct proc_fs_info { >> + struct pid_namespace *pid_ns; >> +}; > >> +static inline struct proc_fs_info *proc_sb(struct super_block *sb) >> +{ >>

[PATCH RFC v3 1/7] proc: add proc_fs_info struct to store proc information

ski <l...@kernel.org> Signed-off-by: Alexey Gladkov <gladkov.ale...@gmail.com> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/locks.c | 6 +++-- fs/proc/base.c | 30 +++-- fs/proc/inode.c

[PATCH RFC v3 1/7] proc: add proc_fs_info struct to store proc information

-January/004215.html [2] http://www.openwall.com/lists/kernel-hardening/2017/10/05/5 [3] http://lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.14 Cc: Kees Cook Cc: Greg Kroah-Hartman Suggested-by: Andy Lutomirski Signed-off-by: Alexey Gladkov Signed-off-by: Djalal Haro

[PATCH RFC v3 2/7] proc: move /proc/{self|thread-self} dentries to proc_fs_info

...@gmail.com> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/proc/base.c| 4 ++-- fs/proc/root.c| 8 fs/proc/self.c| 3 +-- fs/proc/thread_self.c | 5 ++--- include/linux/pid_namespace.h | 4 +--- include/linux/p

[PATCH RFC v3 2/7] proc: move /proc/{self|thread-self} dentries to proc_fs_info

, and we want to make sure that unmounting a private procfs won't clash with other procfs mounts. Cc: Kees Cook Cc: Greg Kroah-Hartman Suggested-by: Andy Lutomirski Signed-off-by: Alexey Gladkov Signed-off-by: Djalal Harouni --- fs/proc/base.c| 4 ++-- fs/proc/root.c

[PATCH RFC v3 3/7] proc: add helpers to set and get proc hidepid and gid mount options

. First lets fix the access. Cc: Kees Cook <keesc...@chromium.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Suggested-by: Andy Lutomirski <l...@kernel.org> Signed-off-by: Alexey Gladkov <gladkov.ale...@gmail.com> Signed-off-by: Djalal Harouni <tix...@gma

[PATCH RFC v3 3/7] proc: add helpers to set and get proc hidepid and gid mount options

. First lets fix the access. Cc: Kees Cook Cc: Greg Kroah-Hartman Suggested-by: Andy Lutomirski Signed-off-by: Alexey Gladkov Signed-off-by: Djalal Harouni --- fs/proc/base.c | 16 +--- fs/proc/inode.c | 5 +++-- fs/proc/internal.h | 2 +- fs/proc/root.c

[PATCH RFC v3 5/7] proc: move hidepid definitions to proc files

bit to where it really belongs. Cc: Kees Cook <keesc...@chromium.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Andy Lutomirski <l...@kernel.org> Signed-off-by: Alexey Gladkov <gladkov.ale...@gmail.com> Signed-off-by: Djalal Harouni <tix...@gmail.com> ---

[PATCH RFC v3 5/7] proc: move hidepid definitions to proc files

bit to where it really belongs. Cc: Kees Cook Cc: Greg Kroah-Hartman Cc: Andy Lutomirski Signed-off-by: Alexey Gladkov Signed-off-by: Djalal Harouni --- include/linux/pid_namespace.h | 6 -- include/linux/proc_fs.h | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff

[PATCH RFC v3 6/7] proc: support new 'pids=all|ptraceable' mount option

.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Suggested-by: Andy Lutomirski <l...@kernel.org> Signed-off-by: Alexey Gladkov <gladkov.ale...@gmail.com> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/proc/base.c | 36 +

[PATCH RFC v3 6/7] proc: support new 'pids=all|ptraceable' mount option

Suggested-by: Andy Lutomirski Signed-off-by: Alexey Gladkov Signed-off-by: Djalal Harouni --- fs/proc/base.c | 36 +--- fs/proc/inode.c | 6 +- fs/proc/root.c | 20 ++-- include/linux/proc_fs.h | 30 +

[PATCH RFC v3 4/7] proc: support mounting private procfs instances inside same pid namespace

/2/407 [6] https://lkml.org/lkml/2017/5/3/357 Cc: Kees Cook <keesc...@chromium.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Suggested-by: Andy Lutomirski <l...@kernel.org> Signed-off-by: Alexey Gladkov <gladkov.ale...@gmail.com> Signed-off-by: Djalal Har

[PATCH RFC v3 7/7] proc: flush dcache entries from all procfs instances

y Lutomirski <l...@kernel.org> Cc: Alexey Gladkov <gladkov.ale...@gmail.com> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/proc/base.c| 27 +++- fs/proc/inode.c | 9 +++- fs/proc/root.c| 10 +

[PATCH RFC v3 4/7] proc: support mounting private procfs instances inside same pid namespace

07 [6] https://lkml.org/lkml/2017/5/3/357 Cc: Kees Cook Cc: Greg Kroah-Hartman Suggested-by: Andy Lutomirski Signed-off-by: Alexey Gladkov Signed-off-by: Djalal Harouni --- fs/proc/base.c| 4 +-- fs/proc/inode.c | 14 +--- fs/proc/root.c| 7

[PATCH RFC v3 7/7] proc: flush dcache entries from all procfs instances

Flush dcache entries of a task when it terminates. The task may have showed up in multiple procfs mounts per pid namespace, and we need to walk the mounts and invalidate any left entires. Cc: Kees Cook Cc: Greg Kroah-Hartman Cc: Andy Lutomirski Cc: Alexey Gladkov Signed-off-by: Djalal Harouni

[PATCH RFC v3 0/7] proc: modernize proc to support multiple private instances

ndy Lutomirski <l...@kernel.org> *) Many bug fixes. # Changes since RFC v1: *) Removed 'unshared' mount option and replaced it with 'limit_pids' which is attached to the current procfs mount. Suggested-by Andy Lutomirski <l...@kernel.org> *) Do not fill dcache with pid entries

[PATCH RFC v3 0/7] proc: modernize proc to support multiple private instances

ug fixes. # Changes since RFC v1: *) Removed 'unshared' mount option and replaced it with 'limit_pids' which is attached to the current procfs mount. Suggested-by Andy Lutomirski *) Do not fill dcache with pid entries that we can not ptrace. *) Many bug fixes. Djalal Harouni (7): [PATCH

Re: [PATCH v2 2/2] pidmap(2)

Hi Alexey, On Sun, Sep 24, 2017 at 9:08 PM, Alexey Dobriyan wrote: > From: Tatsiana Brouka > > Implement system call for bulk retrieveing of pids in binary form. > > Using /proc is slower than necessary: 3 syscalls + another 3 for each thread + >

Re: [PATCH v2 2/2] pidmap(2)

Hi Alexey, On Sun, Sep 24, 2017 at 9:08 PM, Alexey Dobriyan wrote: > From: Tatsiana Brouka > > Implement system call for bulk retrieveing of pids in binary form. > > Using /proc is slower than necessary: 3 syscalls + another 3 for each thread + > converting with atoi() + instantiating dentries

Re: [PATCH 1/2] pidmap(2)

Hi Alexey, On Thu, Sep 7, 2017 at 4:04 AM, Andy Lutomirski wrote: > On Wed, Sep 6, 2017 at 2:04 AM, Alexey Dobriyan wrote: >> On 9/6/17, Randy Dunlap wrote: >>> On 09/05/17 15:53, Andrew Morton wrote: [...] >>> >>> also, I expect

Re: [PATCH 1/2] pidmap(2)

Hi Alexey, On Thu, Sep 7, 2017 at 4:04 AM, Andy Lutomirski wrote: > On Wed, Sep 6, 2017 at 2:04 AM, Alexey Dobriyan wrote: >> On 9/6/17, Randy Dunlap wrote: >>> On 09/05/17 15:53, Andrew Morton wrote: [...] >>> >>> also, I expect that the tiny kernel people will want kconfig options for >>>

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

Hi Kees, On Thu, Jun 1, 2017 at 9:10 PM, Kees Cook <keesc...@google.com> wrote: > On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni <tix...@gmail.com> wrote: ... > >> BTW Kees, also in next version I won't remove the >> capable(CAP_NET_ADMIN) check from [

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

Hi Kees, On Thu, Jun 1, 2017 at 9:10 PM, Kees Cook wrote: > On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni wrote: ... > >> BTW Kees, also in next version I won't remove the >> capable(CAP_NET_ADMIN) check from [1] >> even if there is the new request_mo

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 30, 2017 at 7:59 PM, Kees Cook wrote: [...] >>> I see a few options: >>> >>> 1) keep what you have for v4, and hope other places don't use >>> __request_module. (I'm not a fan of this.) >> >> Yes even if it is documented I wouldn't bet on it, though. :-) > > Okay,

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 30, 2017 at 7:59 PM, Kees Cook wrote: [...] >>> I see a few options: >>> >>> 1) keep what you have for v4, and hope other places don't use >>> __request_module. (I'm not a fan of this.) >> >> Yes even if it is documented I wouldn't bet on it, though. :-) > > Okay, we seem to agree:

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Tue, May 23, 2017 at 9:48 AM, Solar Designer <so...@openwall.com> wrote: >> >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer <so...@openwall.com> >> >>> wrote: >> >>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Tue, May 23, 2017 at 9:48 AM, Solar Designer wrote: >> >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer >> >>> wrote: >> >>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: >> >>> >>

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 23, 2017 at 9:19 PM, Kees Cook <keesc...@google.com> wrote: > On Tue, May 23, 2017 at 3:29 AM, Djalal Harouni <tix...@gmail.com> wrote: [...] >> I think if there is an interface request_module_capable() , then code >> will use it. The DCCP code path did no

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 23, 2017 at 9:19 PM, Kees Cook wrote: > On Tue, May 23, 2017 at 3:29 AM, Djalal Harouni wrote: [...] >> I think if there is an interface request_module_capable() , then code >> will use it. The DCCP code path did not check capabilities at all and >> called re

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017 at 2:54 PM, Eric W. Biederman wrote: > Jeff Layton writes: > >> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote: >>> David Howells writes: >>> >>> > Here are a set of patches to define a container

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017 at 2:54 PM, Eric W. Biederman wrote: > Jeff Layton writes: > >> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote: >>> David Howells writes: >>> >>> > Here are a set of patches to define a container object for the kernel and >>> > to provide some methods to create

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017 at 12:22 AM, Jeff Layton wrote: > On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote: >> David Howells writes: >> >> > Here are a set of patches to define a container object for the kernel and >> > to provide some methods to

Re: [RFC][PATCH 0/9] Make containers kernel objects

On Tue, May 23, 2017 at 12:22 AM, Jeff Layton wrote: > On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote: >> David Howells writes: >> >> > Here are a set of patches to define a container object for the kernel and >> > to provide some methods to create and manipulate them. >> > >> > The

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Tue, May 23, 2017 at 1:38 AM, Andy Lutomirski <l...@kernel.org> wrote: > On Mon, May 22, 2017 at 4:07 PM, Kees Cook <keesc...@chromium.org> wrote: >> On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni <tix...@gmail.com> wrote: >>> On Mon, May 22,

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Tue, May 23, 2017 at 1:38 AM, Andy Lutomirski wrote: > On Mon, May 22, 2017 at 4:07 PM, Kees Cook wrote: >> On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote: >>> On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote: >>>> On Mon, May 22, 2017 at 03:49:15

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 23, 2017 at 12:20 AM, Kees Cook <keesc...@chromium.org> wrote: > On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni <tix...@gmail.com> wrote: >> This is a preparation patch for the module auto-load restriction feature. >> >> In order to restrict mo

Re: [PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

On Tue, May 23, 2017 at 12:20 AM, Kees Cook wrote: > On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni wrote: >> This is a preparation patch for the module auto-load restriction feature. >> >> In order to restrict module auto-load operations we need to check if the >>

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 6:43 PM, Solar Designer <so...@openwall.com> wrote: > On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: >> On Mon, May 22, 2017 at 2:08 PM, Solar Designer <so...@openwall.com> wrote: >> > On Mon, May 22, 2017 at 01:57:03

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote: > On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote: >> On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote: >> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote: >> >> *) When modu

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

Hi Alexander, On Mon, May 22, 2017 at 2:08 PM, Solar Designer <so...@openwall.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 mo

Re: [kernel-hardening] [PATCH v4 next 0/3] modules: automatic module loading restrictions

Hi Alexander, On Mon, May 22, 2017 at 2:08 PM, Solar Designer 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 >>

[PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction

all.com/lists/oss-security/2017/02/22/3 [2] http://www.openwall.com/lists/oss-security/2017/03/29/2 [3] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074 Cc: Ben Hutchings <ben.hutchi...@codethink.co.uk> Cc: Rusty Russell <ru...@rustcorp.com.au> Cc: James Mor

[PATCH v4 next 2/3] modules:capabilities: automatic module loading restriction

all.com/lists/oss-security/2017/02/22/3 [2] http://www.openwall.com/lists/oss-security/2017/03/29/2 [3] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074 Cc: Ben Hutchings Cc: Rusty Russell Cc: James Morris Cc: Serge Hallyn Cc: Andy Lutomirski Suggested-by: Kees Cook Signe

[PATCH v4 next 3/3] modules:capabilities: add a per-task modules auto-load mode

om/xairy/kernel-exploits/tree/master/CVE-2017-6074 Cc: Ben Hutchings <ben.hutchi...@codethink.co.uk> Cc: Rusty Russell <ru...@rustcorp.com.au> Cc: James Morris <james.l.mor...@oracle.com> Cc: Serge Hallyn <se...@hallyn.com> Cc: Andy Lutomirski &l

[PATCH v4 next 3/3] modules:capabilities: add a per-task modules auto-load mode

will be restricted to trigger automatic module loading, other parts of the system can continue to use the system as it is which is the case of the desktop. [1] http://www.openwall.com/lists/oss-security/2017/02/22/3 [2] http://www.openwall.com/lists/oss-security/2017/03/29/2 [3] https://gith

[PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

by Rusty Russell: https://lkml.org/lkml/2017/4/26/735 Cc: Serge Hallyn <se...@hallyn.com> Cc: Andy Lutomirski <l...@kernel.org> Suggested-by: Rusty Russell <ru...@rustcorp.com.au> Suggested-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Djalal Harouni <tix...@gmail.co

[PATCH v4 next 1/3] modules:capabilities: allow __request_module() to take a capability argument

by Rusty Russell: https://lkml.org/lkml/2017/4/26/735 Cc: Serge Hallyn Cc: Andy Lutomirski Suggested-by: Rusty Russell Suggested-by: Kees Cook Signed-off-by: Djalal Harouni [1] https://lkml.org/lkml/2017/4/24/7 --- include/linux/kmod.h | 15 --- include/linux/lsm_hooks.h |

Re: [RFC][PATCH 0/9] VFS: Introduce mount context

On Wed, May 3, 2017 at 6:04 PM, David Howells wrote: > > Here are a set of patches to create a mount context prior to setting up a > new mount, populating it with the parsed options/binary data and then > effecting the mount. > > This allows namespaces and other information

Re: [RFC][PATCH 0/9] VFS: Introduce mount context

On Wed, May 3, 2017 at 6:04 PM, David Howells wrote: > > Here are a set of patches to create a mount context prior to setting up a > new mount, populating it with the parsed options/binary data and then > effecting the mount. > > This allows namespaces and other information to be conveyed through

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Hi Serge, On Thu, May 4, 2017 at 4:58 PM, Serge E. Hallyn <se...@hallyn.com> wrote: > On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote: >> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni <tix...@gmail.com> wrote: >> > On Sat, Apr 22, 2017

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Hi Serge, On Thu, May 4, 2017 at 4:58 PM, Serge E. Hallyn wrote: > On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote: >> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni wrote: >> > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski >> > wrote: &g

  1   2   3   4   5   6   >