[PATCH v3 1/2] modules:capabilities: automatic module loading restriction

omatic module loading of netdev-tunl0 by "ip"[1398] was denied [ 416.040578] Automatic module loading of tunl0 by "ip"[1398] was denied $ cat /proc/sys/kernel/modules_autoload 2 Cc: Serge Hallyn <se...@hallyn.com> Cc: Andy Lutomirski <l...@kernel.org> Suggested-by:

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

1362] was denied Cc: Serge Hallyn <se...@hallyn.com> Cc: Andy Lutomirski <l...@kernel.org> Suggested-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- Documentation/filesystems/proc.txt | 3 ++ Documentation/prctl/modules_autoload.tx

[PATCH v3 0/2] modules:capabilities: automatic module loading restrictions

Hi List, This is an update of the previous two RFCs that implemented module auto-load restriction as a stackable LSM [1] [2]. The previous versions were presented as a stackable LSM, this new version is implemented as a core kernel feature inside the capability subsystem. This new version is

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

On Thu, Apr 20, 2017 at 12:20 AM, Djalal Harouni <tix...@gmail.com> wrote: [...] > +/* Returns task's modules_autoload */ > +static inline void task_copy_modules_autoload(struct task_struct *dest, > + struct task_struct *src) >

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

9, 2017 at 4:43 PM, Kees Cook <keesc...@chromium.org> wrote: >>>> On Wed, Apr 19, 2017 at 4:15 PM, Andy Lutomirski <l...@kernel.org> wrote: >>>>> On Wed, Apr 19, 2017 at 3:20 PM, Djalal Harouni <tix...@gmail.com> wrote: >>>>>> +/* Sets task

Re: [RFC] Add option to mount only a pids subset

On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski wrote: > > On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov > wrote: > > > > After discussion with Oleg Nesterov I reimplement my patch as an additional > > option for /proc. This option affects the

Re: [kernel-hardening] [PATCH v5 06/10] seccomp,landlock: Handle Landlock events per process hierarchy

On Wed, Feb 22, 2017 at 2:26 AM, Mickaël Salaün wrote: > The seccomp(2) syscall can be use to apply a Landlock rule to the > current process. As with a seccomp filter, the Landlock rule is enforced > for all its future children. An inherited rule tree can be updated >

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

Hi Rusty, On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Djalal Harouni <tix...@gmail.com> writes: >> When value is (1), task must have CAP_SYS_MODULE to be able to trigger a >> module auto-load operation, or CAP_NET_ADMIN for modules

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

On Thu, Apr 27, 2017 at 4:07 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: > Djalal Harouni <tix...@gmail.com> writes: >> Hi Rusty, >> >> On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell <ru...@rustcorp.com.au> wrote: >>> Djalal Harouni <tix...@g

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

On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski wrote: [...] >>> I personally like my implicit_rights idea, and it might be interesting >>> to prototype it. >> >> I don't like blocking a needed feature behind a large super-feature >> that doesn't exist yet. We'd be able to

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

On Sat, Apr 22, 2017 at 2:12 AM, Djalal Harouni <tix...@gmail.com> wrote: > On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski <l...@kernel.org> wrote: > [...] >>>> I personally like my implicit_rights idea, and it might be interesting >>>> to prototype

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

On Mon, Apr 24, 2017 at 8:02 PM, Kees Cook <keesc...@chromium.org> wrote: > On Mon, Apr 24, 2017 at 7:25 AM, Djalal Harouni <tix...@gmail.com> wrote: >> On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keesc...@chromium.org> wrote: >>> On Fri, Apr 21, 2017 at 11:51

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

On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook <keesc...@chromium.org> wrote: > On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski <l...@kernel.org> wrote: >> On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni <tix...@gmail.com> wrote: >>> On Sat, Apr 22, 2017 at 1:51

[PATCH RFC v2 0/6] proc: support private proc instances per pidnamespace

t;l...@kernel.org> *) Do not fill dcache with pid entries that we can not ptrace. *) Many bug fixes. Djalal Harouni (6): [PATCH 1/6] proc: add proc_fs_info struct to store proc information [PATCH 2/6] proc: move /proc/{self|thread-self} dentries to proc_fs_info [PATCH 3/6] proc: add helpers

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

, unmounting a private procfs won't clash with other procfs mounts. Cc: Kees Cook <keesc...@chromium.org> Cc: Andy Lutomirski <l...@kernel.org> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/proc/base.c| 4 ++-- fs/proc/root.c| 8 --

[PATCH RFC v2 1/6] proc: add proc_fs_info struct to store proc information

: Kees Cook <keesc...@chromium.org> Suggested-by: Andy Lutomirski <l...@kernel.org> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/locks.c | 6 +++-- fs/proc/base.c | 31 +-- fs/proc/inode.c | 8 +++--- fs/proc/ro

[PATCH RFC v2 5/6] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option

If "limit_pids=1" mount option is set then do not instantiate pids that we can not ptrace. "limit_pids=1" means that procfs should only contain pids that the caller can ptrace. Cc: Kees Cook <keesc...@chromium.org> Cc: Andy Lutomirski <l...@kernel.org> Si

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

filters. Later Yama LSM can be updated to check that processes are able only able to see their children inside /proc/. [1] https://lkml.org/lkml/2017/3/31/324 Cc: Kees Cook <keesc...@chromium.org> Suggested-by: Andy Lutomirski <l...@kernel.org> Signed-off-by: Djalal Harouni <t

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

This is a cleaning patch to add helpers to set and get proc mount options instead of directly using them. This make it easy to track what's happening and easy to update in future. Cc: Kees Cook <keesc...@chromium.org> Cc: Andy Lutomirski <l...@kernel.org> Signed-off-by: Djalal

[PATCH RFC v2 6/6] proc: flush task dcache entries from all procfs instances

This allows to flush dcache entries of a task on multiple procfs mounts per pid namespace. Cc: Kees Cook <keesc...@chromium.org> Cc: Andy Lutomirski <l...@kernel.org> Signed-off-by: Djalal Harouni <tix...@gmail.com> --- fs/proc/base.c| 27 ++

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

On Tue, May 2, 2017 at 6:33 PM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, May 2, 2017 at 7:29 AM, Djalal Harouni <tix...@gmail.com> wrote: >> On Thu, Apr 27, 2017 at 12:13 AM, Andy Lutomirski <l...@kernel.org> wrote: >>> On Tue, Apr 25, 2017 at 5:23

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: [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: [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: [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: [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: [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

[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 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 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

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: [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 v3 2/2] modules:capabilities: add a per-task modules autoload restriction

On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni <tix...@gmail.com> wrote: > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski <l...@amacapital.net> wrote: [...] >> >> My point is that all of these need some way to handle configuration >> and inheritance, and I don

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: [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: [PATCH RFC v2 5/6] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option

Hello Andy, (Sorry for my late response) On Thu, Apr 27, 2017 at 12:09 AM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Apr 25, 2017 at 5:23 AM, Djalal Harouni <tix...@gmail.com> wrote: >> If "limit_pids=1" mount option is set then do not instantiate

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

On Thu, Apr 27, 2017 at 12:13 AM, Andy Lutomirski <l...@kernel.org> wrote: > On Tue, Apr 25, 2017 at 5:23 AM, Djalal Harouni <tix...@gmail.com> wrote: [...] >> We have to align procfs and modernize it to have a per mount context >> where at least the mount option do

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 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 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 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 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 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 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 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 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

[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 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 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 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

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 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 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: [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: [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 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: [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: [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: [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: [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: [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

[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 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 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 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 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 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 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

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 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: [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

[PATCH] iwlwifi: mvm: make debugfs write() operations write up to count bytes

the initializer from 'char buf[x] = {}' to the explicit memset() as it is done in other places of the same file. Cc: sta...@vger.kernel.org Signed-off-by: Djalal Harouni --- Patch compile tested only. Dual BSD/GPLv2 license: Ok drivers/net/wireless/iwlwifi/mvm/debugfs.c | 28

Re: [PATCH] iwlwifi: mvm: make debugfs write() operations write up to count bytes

t; Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration N

Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

Cc'ed more people, On Tue, Aug 27, 2013 at 06:24:06PM +0100, Djalal Harouni wrote: > Hi Al, > > On Mon, Aug 26, 2013 at 06:20:55PM +0100, Al Viro wrote: > > On Mon, Aug 26, 2013 at 09:49:48AM -0700, Eric W. Biederman wrote: > > > > > How does changing the permissi

Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

On Wed, Aug 28, 2013 at 01:49:06PM -0700, Kees Cook wrote: > On Wed, Aug 28, 2013 at 1:11 PM, Djalal Harouni wrote: [...] > >> 2) > >> The commit log says also: > >> "if you open a file before the target does suid-root exec, you'll be still > >> able t

Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

hey are correct. Perhaps you didn't take a closer look Thanks Eric -- Djalal Harouni http://opendz.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

(Sorry for my late response) On Thu, Aug 29, 2013 at 03:14:32PM -0700, Kees Cook wrote: > On Thu, Aug 29, 2013 at 2:11 AM, Djalal Harouni wrote: > > Hi Eric, > > > > On Wed, Aug 28, 2013 at 05:26:56PM -0700, Eric W. Biederman wrote: > >> > >> I have take

[PATCH 2/2] procfs: make /proc/*/pagemap 0400

The /proc/*/pagemap contain sensitive information and currently its mode is 0444. Change this to 0400, so the VFS will prevent unprivileged processes from getting file descriptors on arbitrary privileged /proc/*/pagemap files. Cc: Eric W. Biederman Cc: Kees Cook Signed-off-by: Djalal Harouni

[Resend] [PATCH 0/2] procfs: make /proc/*/{stack,syscall,pagemap} 0400

eneral aggreemnt, so I'm resending again but _only_ those two patches. At least we have a VFS protection for now. Djalal Harouni (2): procfs: make /proc/*/{stack,syscall,personality} 0400 procfs: make /proc/*/pagemap 0400 fs/proc/base.c | 16 1 file changed, 8 insertions

[PATCH 1/2] procfs: make /proc/*/{stack,syscall,personality} 0400

Cook Signed-off-by: Djalal Harouni --- fs/proc/base.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 5150706..e69df4b 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -2587,7 +2587,7 @@ static const struct pid_entry

Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task

On Fri, Oct 04, 2013 at 05:35:22PM -0700, Eric W. Biederman wrote: > Andy Lutomirski writes: > > > On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman > > wrote: > >> Andy Lutomirski writes: > >> > >>> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Haro

Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task

On Mon, Oct 07, 2013 at 02:41:33PM -0700, Andy Lutomirski wrote: > On Sat, Oct 5, 2013 at 6:23 AM, Djalal Harouni wrote: > > On Fri, Oct 04, 2013 at 03:17:08PM -0700, Andy Lutomirski wrote: > >> > >> Exactly. Hence the NAK. > > But Having two LSM Hooks there i

Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task

On Wed, Oct 09, 2013 at 11:54:02AM +0100, Djalal Harouni wrote: > On Mon, Oct 07, 2013 at 02:41:33PM -0700, Andy Lutomirski wrote: > > On Sat, Oct 5, 2013 at 6:23 AM, Djalal Harouni wrote: > > > On Fri, Oct 04, 2013 at 03:17:08PM -0700, Andy Lutomirski wrote: > > >>

Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's opener may access task

On Wed, Oct 09, 2013 at 06:27:22PM +0100, Andy Lutomirski wrote: > On Wed, Oct 9, 2013 at 11:54 AM, Djalal Harouni wrote: > > On Mon, Oct 07, 2013 at 02:41:33PM -0700, Andy Lutomirski wrote: > >> On Sat, Oct 5, 2013 at 6:23 AM, Djalal Harouni wrote: > >> > On F

Re: [PATCH v3a] vsprintf: Check real user/group id for %pK

l break userspace then allow open() and cache result for read() Can you emulate the behaviour of kptr_restrict=1 ? If so: 1) perform check during open() and cache data 2) during read() check kptr_restrict==1 check the cached value and if opener had CAP_SYSLOG if so: print something like t

Re: [PATCH v3a] vsprintf: Check real user/group id for %pK

On Mon, Oct 14, 2013 at 11:17:06AM +0100, Djalal Harouni wrote: > On Fri, Oct 11, 2013 at 02:19:14PM +1100, Ryan Mallon wrote: > > On 11/10/13 13:20, Eric W. Biederman wrote: > > > Joe Perches writes: > > > > > >> Some setuid binaries will allow reading of

Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

Hi Eric, (Sorry for the delay, please see below) On Sat, Aug 31, 2013 at 06:44:39PM -0700, Eric W. Biederman wrote: > Djalal Harouni writes: [...] > > Yes Kees, > > > > I did try a year ago to adapt the exec_id from grsecurity and failed > > (and failed again to re

[PATCH 0/12] procfs: protect /proc//* files with file->f_cred

is user_ns and seq_file cleaning. Thanks! [1] https://lkml.org/lkml/2013/8/26/354 [2] https://lkml.org/lkml/2013/8/31/209 Djalal Harouni (12): procfs: add proc_same_open_cred() to check if the cred have changed procfs: add proc_allow_access() to check if file's opener may access task procf

[PATCH 01/12] procfs: add proc_same_open_cred() to check if the cred have changed

changed which means that perhaps we have gain or lost the privileges of processing the /proc file descriptor. So add proc_same_open_cred() to check if the cred have changed. Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni --- fs/proc/base.c | 29

[PATCH 02/12] procfs: add proc_allow_access() to check if file's opener may access task

ntries. This function should be used with the ptrace_may_access() check. Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni --- fs/proc/base.c | 56 ++ fs/proc/internal.h | 2 ++ 2 files changed, 58 insertions(+) diff --git a/f

[PATCH 03/12] procfs: Document the proposed solution to protect procfs entries

Note the proposed solution to protect sensitive procfs entries as code comment. Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni --- fs/proc/base.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/fs/proc/base.c b/fs/proc/base.c index c29eeae..8d21316 100644

[PATCH 04/12] seq_file: Make seq_file able to access the file's opener cred

per seq_f_cred() to return it. Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni --- include/linux/seq_file.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h index 4e32edc..ec07709 100644 --- a/include/linux/seq_file.h ++

[PATCH 05/12] seq_file: set the seq_file->f_cred during seq_open()

system call. Set the seq_file->f_cred to file->f_cred during seq_open(). Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni --- fs/seq_file.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/seq_file.c b/fs/seq_file.c index 3135c25..a5e5b98 100644 --- a/fs/seq_file.c ++

[PATCH 06/12] procfs: make /proc/*/stack 0400

Eric W. Biederman Signed-off-by: Djalal Harouni --- fs/proc/base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 8d21316..bb90171 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -2710,7 +2710,7 @@ static const struct pid

[PATCH 07/12] procfs: add permission checks on the file's opener of /proc/*/stack

Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni --- fs/proc/base.c | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index bb90171..d6a17b3 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -402,6

[PATCH 08/12] procfs: add permission checks on the file's opener of /proc/*/personality

If current's cred have changed between ->open() and ->read(), then call proc_allow_access() to check if the original file's opener had enough permissions to access the /proc/*/personality entry during ->read(). Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni ---

[PATCH 09/12] procfs: add permission checks on the file's opener of /proc/*/stat

enough permissions to read these sensitive fields. The patch also adds a previously missing signal->cred_guard_mutex lock. This patch does not break userspace since it only hides the fields that were supposed to be protected. Cc: Kees Cook Cc: Eric W. Biederman Signed-off-by: Djalal Harouni ---

<    1   2   3   4   5   6   >