Re: [v6 1/2] raid6/altivec: Add vpermxor implementation for raid6 Q syndrome

On Wed, Aug 9, 2017 at 11:26 PM, Michael Ellerman <m...@ellerman.id.au> wrote: > Matt Brown <matthew.brown@gmail.com> writes: > >> This patch uses the vpermxor instruction to optimise the raid6 Q syndrome. >> This instruction was made available with POWER8,

Re: [v6 1/2] raid6/altivec: Add vpermxor implementation for raid6 Q syndrome

On Wed, Aug 9, 2017 at 11:26 PM, Michael Ellerman wrote: > Matt Brown writes: > >> This patch uses the vpermxor instruction to optimise the raid6 Q syndrome. >> This instruction was made available with POWER8, ISA version 2.07. >> It allows for both vperm and vxor

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/13/17 3:51 PM, Serge E. Hallyn wrote: > Quoting Mimi Zohar (zo...@linux.vnet.ibm.com): >> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote: >> The question is really from a security perspective which is better? >> Obviously, as v2 of the patch set changed from using p

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/13/17 3:51 PM, Serge E. Hallyn wrote: > Quoting Mimi Zohar (zo...@linux.vnet.ibm.com): >> On Thu, 2017-07-13 at 08:39 -0400, Matt Brown wrote: >> The question is really from a security perspective which is better? >> Obviously, as v2 of the patch set changed from using p

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/11/17 3:31 PM, Mimi Zohar wrote: > On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote: > >> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be >> releasing a version 3 soon. I have also added securityfs support to >> shebang that will allow users t

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

On 7/11/17 3:31 PM, Mimi Zohar wrote: > On Tue, 2017-07-11 at 13:49 -0400, Matt Brown wrote: > >> I have merged my TPE LSM with Mimi Zohar's shebang LSM and will be >> releasing a version 3 soon. I have also added securityfs support to >> shebang that will allow users t

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

ere are only 3 possible solutions to this problem: > 1 - SARA gives up its configuration mechanics and starts using xattrs > 2 - TPE/shebang gives up xattrs and starts using SARA-style configurations > 3 - SARA adds xattrs support to its quiver *and* TPE/shebang adds SARA-style &g

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

: > 1 - SARA gives up its configuration mechanics and starts using xattrs > 2 - TPE/shebang gives up xattrs and starts using SARA-style configurations > 3 - SARA adds xattrs support to its quiver *and* TPE/shebang adds SARA-style > configuration support. > > The solut

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

On 06/11/2017 07:30 AM, Mickaël Salaün wrote: On 08/06/2017 21:01, Matt Brown wrote: On 6/8/17 2:37 PM, Alan Cox wrote: http://phrack.org/issues/52/6.html#article | A trusted path is one that is inside a root owned directory that | is not group or world writable. /bin, /usr/bin, /usr/local

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

On 06/11/2017 07:30 AM, Mickaël Salaün wrote: On 08/06/2017 21:01, Matt Brown wrote: On 6/8/17 2:37 PM, Alan Cox wrote: http://phrack.org/issues/52/6.html#article | A trusted path is one that is inside a root owned directory that | is not group or world writable. /bin, /usr/bin, /usr/local

Re: [kernel-hardening] Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On 6/9/17 9:16 AM, Mimi Zohar wrote: > On Fri, 2017-06-09 at 05:55 -0700, Kees Cook wrote: >> On Fri, Jun 9, 2017 at 3:18 AM, Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: >>> On Thu, 2017-06-08 at 23:50 -0400, Matt Brown wrote: >>>>>> >>>>>

Re: [kernel-hardening] Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On 6/9/17 9:16 AM, Mimi Zohar wrote: > On Fri, 2017-06-09 at 05:55 -0700, Kees Cook wrote: >> On Fri, Jun 9, 2017 at 3:18 AM, Mimi Zohar wrote: >>> On Thu, 2017-06-08 at 23:50 -0400, Matt Brown wrote: >>>>>> >>>>>> * Issues: >>>&g

Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On 6/9/17 8:55 AM, Kees Cook wrote: > On Fri, Jun 9, 2017 at 3:18 AM, Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: >> On Thu, 2017-06-08 at 23:50 -0400, Matt Brown wrote: >>>>> >>>>> * Issues: >>>>>* Can be bypassed by interpreted

Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On 6/9/17 8:55 AM, Kees Cook wrote: > On Fri, Jun 9, 2017 at 3:18 AM, Mimi Zohar wrote: >> On Thu, 2017-06-08 at 23:50 -0400, Matt Brown wrote: >>>>> >>>>> * Issues: >>>>>* Can be bypassed by interpreted languages such as python. You

Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On 06/08/2017 10:38 PM, Kees Cook wrote: On Wed, Jun 7, 2017 at 8:43 PM, Matt Brown <m...@nmatt.com> wrote: This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature. It also adds features and config options that were found in Corey Henderson's tpe-lkm p

Re: [PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

On 06/08/2017 10:38 PM, Kees Cook wrote: On Wed, Jun 7, 2017 at 8:43 PM, Matt Brown wrote: This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature. It also adds features and config options that were found in Corey Henderson's tpe-lkm project. Modifications from Brad

Re: [kernel-hardening] [PATCH 0/6] LSM: Security module blob management

On 6/8/17 4:43 PM, Casey Schaufler wrote: > Subject: [PATCH 0/6] LSM: Security module blob management > > This patch set moves management of security blobs out of > the Linux security modules and into the security module > infrastructure. This allows "major" security modules that > use blobs to

Re: [kernel-hardening] [PATCH 0/6] LSM: Security module blob management

On 6/8/17 4:43 PM, Casey Schaufler wrote: > Subject: [PATCH 0/6] LSM: Security module blob management > > This patch set moves management of security blobs out of > the Linux security modules and into the security module > infrastructure. This allows "major" security modules that > use blobs to

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

On 6/8/17 2:37 PM, Alan Cox wrote: >> http://phrack.org/issues/52/6.html#article >> >> | A trusted path is one that is inside a root owned directory that >> | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are >> | (under normal circumstances) considered trusted. Any non-root >>

Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

On 6/8/17 2:37 PM, Alan Cox wrote: >> http://phrack.org/issues/52/6.html#article >> >> | A trusted path is one that is inside a root owned directory that >> | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are >> | (under normal circumstances) considered trusted. Any non-root >>

[PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

Trusted Path Execution (TPE) Patch Versions: v1: * initial patch introduction v2: * included copyright notice from Brad Spengler and Corey Henderson * reversed the invert_gid logic. tpe.gid now defaults to being the trusted group rather than the untrusted group. * fixed race condition by

[PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

into the untrusted group. This means that all other groups become trusted. This sysctl is helpful when you want TPE restrictions to be limited to a small subset of users. Signed-off-by: Matt Brown <m...@nmatt.com> --- Documentation/security/tpe.txt | 59 +++ MAINTAINERS

[PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM

Trusted Path Execution (TPE) Patch Versions: v1: * initial patch introduction v2: * included copyright notice from Brad Spengler and Corey Henderson * reversed the invert_gid logic. tpe.gid now defaults to being the trusted group rather than the untrusted group. * fixed race condition by

[PATCH v2 1/1] Add Trusted Path Execution as a stackable LSM

into the untrusted group. This means that all other groups become trusted. This sysctl is helpful when you want TPE restrictions to be limited to a small subset of users. Signed-off-by: Matt Brown --- Documentation/security/tpe.txt | 59 +++ MAINTAINERS| 5 + include/linux

Re: [kernel-hardening] Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

On 06/04/2017 01:47 AM, Eric Biggers wrote: On Sun, Jun 04, 2017 at 01:24:13AM -0400, Matt Brown wrote: On 06/03/2017 02:33 AM, Al Viro wrote: On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote: +static int tpe_bprm_set_creds(struct linux_binprm *bprm) +{ + struct file *file

Re: [kernel-hardening] Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

On 06/04/2017 01:47 AM, Eric Biggers wrote: On Sun, Jun 04, 2017 at 01:24:13AM -0400, Matt Brown wrote: On 06/03/2017 02:33 AM, Al Viro wrote: On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote: +static int tpe_bprm_set_creds(struct linux_binprm *bprm) +{ + struct file *file

Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

On 06/03/2017 02:33 AM, Al Viro wrote: On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote: +static int tpe_bprm_set_creds(struct linux_binprm *bprm) +{ + struct file *file = bprm->file; + struct inode *inode = d_backing_inode(file->f_path.dentry->d_parent); +

Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

On 06/03/2017 02:33 AM, Al Viro wrote: On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote: +static int tpe_bprm_set_creds(struct linux_binprm *bprm) +{ + struct file *file = bprm->file; + struct inode *inode = d_backing_inode(file->f_path.dentry->d_parent); +

Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

On 06/03/2017 06:39 AM, Jann Horn wrote: On Sat, Jun 3, 2017 at 7:53 AM, Matt Brown <m...@nmatt.com> wrote: This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature in Grsecurity and also incorporates logging ideas from cormander's tpe-lkm. Modification

Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

On 06/03/2017 06:39 AM, Jann Horn wrote: On Sat, Jun 3, 2017 at 7:53 AM, Matt Brown wrote: This patch was modified from Brad Spengler's Trusted Path Execution (TPE) feature in Grsecurity and also incorporates logging ideas from cormander's tpe-lkm. Modifications from the Grsecurity

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 06/03/2017 06:00 PM, Alan Cox wrote: TIOCSLCKTRMIOS That one I'm more dubious about TIOCSLTC TIOCSSOFTCAR tty_io.c also has a few and n_tty has a couple we'd want. would it be overkill to have a sysctl kernel.ttyioctlwhitelist.X where X is one of the ioctls above? Why would anyone

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 06/03/2017 06:00 PM, Alan Cox wrote: TIOCSLCKTRMIOS That one I'm more dubious about TIOCSLTC TIOCSSOFTCAR tty_io.c also has a few and n_tty has a couple we'd want. would it be overkill to have a sysctl kernel.ttyioctlwhitelist.X where X is one of the ioctls above? Why would anyone

[PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

replaces binary used by a privileged user with a malicious one * This situation arises when administrator of a system leaves a binary as world writable. * TPE is very effective against this threat model Signed-off-by: Matt Brown <m...@nmatt.com> --- MAINTAINERS

[PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM

replaces binary used by a privileged user with a malicious one * This situation arises when administrator of a system leaves a binary as world writable. * TPE is very effective against this threat model Signed-off-by: Matt Brown --- MAINTAINERS | 5 ++ include/linux

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 4:05 PM, Alan Cox wrote: >> Can't we also have a sysctl that toggles if CAP_SYS_ADMIN is involved in >> this whitelist check? Otherwise someone might leave things out of the >> whitelist just because they want to use those ioctls as a privileged >> process. Also restricting a privileged

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 4:05 PM, Alan Cox wrote: >> Can't we also have a sysctl that toggles if CAP_SYS_ADMIN is involved in >> this whitelist check? Otherwise someone might leave things out of the >> whitelist just because they want to use those ioctls as a privileged >> process. Also restricting a privileged

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 3:25 PM, Kees Cook wrote: > On Fri, Jun 2, 2017 at 12:22 PM, Matt Brown <m...@nmatt.com> wrote: >> On 6/2/17 2:18 PM, Serge E. Hallyn wrote: >>> Quoting Matt Brown (m...@nmatt.com): >>>> On 6/2/17 12:57 PM, Serge E. Hallyn wrote: >>>>> I

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 3:25 PM, Kees Cook wrote: > On Fri, Jun 2, 2017 at 12:22 PM, Matt Brown wrote: >> On 6/2/17 2:18 PM, Serge E. Hallyn wrote: >>> Quoting Matt Brown (m...@nmatt.com): >>>> On 6/2/17 12:57 PM, Serge E. Hallyn wrote: >>>>> I'm not quite su

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 2:18 PM, Serge E. Hallyn wrote: > Quoting Matt Brown (m...@nmatt.com): >> On 6/2/17 12:57 PM, Serge E. Hallyn wrote: >>> I'm not quite sure what you're asking for here. Let me offer a precise >>> strawman design. I'm sure there are problems with it, it'

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 2:18 PM, Serge E. Hallyn wrote: > Quoting Matt Brown (m...@nmatt.com): >> On 6/2/17 12:57 PM, Serge E. Hallyn wrote: >>> I'm not quite sure what you're asking for here. Let me offer a precise >>> strawman design. I'm sure there are problems with it, it'

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 12:57 PM, Serge E. Hallyn wrote: > Quoting Matt Brown (m...@nmatt.com): >> On 6/2/17 11:36 AM, Serge E. Hallyn wrote: >>> Quoting Matt Brown (m...@nmatt.com): >>>> On 6/1/17 5:24 PM, Alan Cox wrote: >>>>>> There's a differ

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 12:57 PM, Serge E. Hallyn wrote: > Quoting Matt Brown (m...@nmatt.com): >> On 6/2/17 11:36 AM, Serge E. Hallyn wrote: >>> Quoting Matt Brown (m...@nmatt.com): >>>> On 6/1/17 5:24 PM, Alan Cox wrote: >>>>>> There's a differ

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 11:36 AM, Serge E. Hallyn wrote: > Quoting Matt Brown (m...@nmatt.com): >> On 6/1/17 5:24 PM, Alan Cox wrote: >>>> There's a difference between "bugs" and "security bugs". Letting >>> >>> Not really, it's merely a matter of seve

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/2/17 11:36 AM, Serge E. Hallyn wrote: > Quoting Matt Brown (m...@nmatt.com): >> On 6/1/17 5:24 PM, Alan Cox wrote: >>>> There's a difference between "bugs" and "security bugs". Letting >>> >>> Not really, it's merely a matter of seve

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/1/17 5:24 PM, Alan Cox wrote: >> There's a difference between "bugs" and "security bugs". Letting > > Not really, it's merely a matter of severity of result. A non security > bug that hoses your hard disk is to anyone but security nutcases at > least as bad as a security hole. > >> security

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 6/1/17 5:24 PM, Alan Cox wrote: >> There's a difference between "bugs" and "security bugs". Letting > > Not really, it's merely a matter of severity of result. A non security > bug that hoses your hard disk is to anyone but security nutcases at > least as bad as a security hole. > >> security

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/30/2017 10:48 PM, James Morris wrote: On Mon, 29 May 2017, Boris Lukashev wrote: With all due respect sir, i believe your review falls short of the purpose of this effort - to harden the kernel against flaws in userspace. Which effort? Kernel self protection is about protecting

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/30/2017 10:48 PM, James Morris wrote: On Mon, 29 May 2017, Boris Lukashev wrote: With all due respect sir, i believe your review falls short of the purpose of this effort - to harden the kernel against flaws in userspace. Which effort? Kernel self protection is about protecting

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 7:40 PM, Daniel Micay wrote: > On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: >> On 5/30/17 4:22 PM, Daniel Micay wrote: >>>> Thanks, I didn't know that android was doing this. I still think >>>> this >>>> feature >>>> is

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 7:40 PM, Daniel Micay wrote: > On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: >> On 5/30/17 4:22 PM, Daniel Micay wrote: >>>> Thanks, I didn't know that android was doing this. I still think >>>> this >>>> feature >>>> is

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 6:51 PM, Alan Cox wrote: > On Tue, 30 May 2017 12:28:59 -0400 > Matt Brown <m...@nmatt.com> wrote: > >> On 5/30/17 8:24 AM, Alan Cox wrote: >>> Look there are two problems here >>> >>> 1. TIOCSTI has users >> >> I don't se

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 6:51 PM, Alan Cox wrote: > On Tue, 30 May 2017 12:28:59 -0400 > Matt Brown wrote: > >> On 5/30/17 8:24 AM, Alan Cox wrote: >>> Look there are two problems here >>> >>> 1. TIOCSTI has users >> >> I don't see how this is a problem.

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 4:22 PM, Daniel Micay wrote: >> Thanks, I didn't know that android was doing this. I still think this >> feature >> is worthwhile for people to be able to harden their systems against >> this attack >> vector without having to implement a MAC. > > Since there's a capable LSM hook for

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 4:22 PM, Daniel Micay wrote: >> Thanks, I didn't know that android was doing this. I still think this >> feature >> is worthwhile for people to be able to harden their systems against >> this attack >> vector without having to implement a MAC. > > Since there's a capable LSM hook for

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 2:44 PM, Nick Kralevich wrote: > On Tue, May 30, 2017 at 11:32 AM, Stephen Smalley wrote: >>> Seccomp requires the program in question to "opt-in" so to speak and >>> set >>> certain restrictions on itself. However as you state above, any >>> TIOCSTI >>> protection

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 2:44 PM, Nick Kralevich wrote: > On Tue, May 30, 2017 at 11:32 AM, Stephen Smalley wrote: >>> Seccomp requires the program in question to "opt-in" so to speak and >>> set >>> certain restrictions on itself. However as you state above, any >>> TIOCSTI >>> protection doesn't matter if

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 8:24 AM, Alan Cox wrote: > Look there are two problems here > > 1. TIOCSTI has users I don't see how this is a problem. > > 2. You don't actually fix anything > > The underlying problem is that if you give your tty handle to another > process which you don't trust you are screwed.

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 8:24 AM, Alan Cox wrote: > Look there are two problems here > > 1. TIOCSTI has users I don't see how this is a problem. > > 2. You don't actually fix anything > > The underlying problem is that if you give your tty handle to another > process which you don't trust you are screwed.

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 11:20 AM, Casey Schaufler wrote: > On 5/29/2017 8:18 PM, Matt Brown wrote: >> On 5/29/17 10:46 PM, Casey Schaufler wrote: >>> On 5/29/2017 7:00 PM, Matt Brown wrote: >>>> Casey Schaufler, >>>> >>>> First I must start this off

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/30/17 11:20 AM, Casey Schaufler wrote: > On 5/29/2017 8:18 PM, Matt Brown wrote: >> On 5/29/17 10:46 PM, Casey Schaufler wrote: >>> On 5/29/2017 7:00 PM, Matt Brown wrote: >>>> Casey Schaufler, >>>> >>>> First I must start this off

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/29/17 10:46 PM, Casey Schaufler wrote: > On 5/29/2017 7:00 PM, Matt Brown wrote: >> Casey Schaufler, >> >> First I must start this off by saying I really appreciate your presentation >> on >> LSMs that is up on youtube. I've got a LSM in the works and y

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/29/17 10:46 PM, Casey Schaufler wrote: > On 5/29/2017 7:00 PM, Matt Brown wrote: >> Casey Schaufler, >> >> First I must start this off by saying I really appreciate your presentation >> on >> LSMs that is up on youtube. I've got a LSM in the works and y

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

;>> * non-privileged container >>>> * container run inside new user namespace >>> And assuming no other ioctl could be used in an attack. Only there are >>> rather a lot of ways an app with access to a tty can cause mischief if >>> it's the same controlling tty as the higher privileged context that >>> launched it. >>> >>> Properly written code allocates a new pty/tty pair for the lower >>> privileged session. If the code doesn't do that then your change merely >>> modifies the degree of mayhem it can cause. If it does it right then your >>> patch is pointless. >>> >>>> Possible effects on userland: >>>> >>>> There could be a few user programs that would be effected by this >>>> change. >>> In other words, it's yet another weird config option that breaks stuff. >>> >>> >>> NAK v7. >>> >>> Alan >> >> > Thanks, Matt Brown

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

denied, upstream should provide their >> solution to how they want to address the problem (or just an outline >> to guide the hardened folks). > > The impact of a "security measure" can exceed the value provided. > That is, I understand, the basis of the NA

Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/29/17 6:26 PM, Alan Cox wrote: > On Mon, 29 May 2017 17:38:00 -0400 > Matt Brown <m...@nmatt.com> wrote: > >> This introduces the tiocsti_restrict sysctl, whose default is controlled >> via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control >>

Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/29/17 6:26 PM, Alan Cox wrote: > On Mon, 29 May 2017 17:38:00 -0400 > Matt Brown wrote: > >> This introduces the tiocsti_restrict sysctl, whose default is controlled >> via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control >> restricts all T

[PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Acked-by: Serge Hallyn <se...@hallyn.com> Reviewed-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Matt Brown <m...@nmatt.com> --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 8 inc

[PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Acked-by: Serge Hallyn Reviewed-by: Kees Cook Signed-off-by: Matt Brown --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 8 include/linux/tty.h | 2 ++ kernel/sysctl.c | 12 +++

[PATCH v7 1/2] security: tty: Add owner user namespace to tty_struct

ok <keesc...@chromium.org> Signed-off-by: Matt Brown <m...@nmatt.com> --- drivers/tty/tty_io.c | 2 ++ include/linux/tty.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index e6d1a65..c276814 100644 --- a/drivers/tty/tty_io.c +++ b

[PATCH v7 1/2] security: tty: Add owner user namespace to tty_struct

MIN) This combined with the use of user namespace's will allow hardening protections to be built to mitigate container escapes that utilize TTY ioctls such as TIOCSTI. See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256 Acked-by: Serge Hallyn Reviewed-by: Kees Cook Signed-off-by: Matt Br

[PATCH v7 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v7 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

Re: [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/18/17 9:31 AM, Greg KH wrote: > On Fri, May 05, 2017 at 07:20:18PM -0400, Matt Brown wrote: >> This introduces the tiocsti_restrict sysctl, whose default is controlled via >> CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts >> all TIOCSTI

Re: [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 5/18/17 9:31 AM, Greg KH wrote: > On Fri, May 05, 2017 at 07:20:18PM -0400, Matt Brown wrote: >> This introduces the tiocsti_restrict sysctl, whose default is controlled via >> CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts >> all TIOCSTI

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/16/2017 05:43 PM, Peter Dolding wrote: On Wed, May 17, 2017 at 12:28 AM, Kees Cook <keesc...@chromium.org> wrote: On Tue, May 16, 2017 at 5:22 AM, Matt Brown <m...@nmatt.com> wrote: On 05/16/2017 05:01 AM, Peter Dolding wrote: I could see a case being make for CAP_SY

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/16/2017 05:43 PM, Peter Dolding wrote: On Wed, May 17, 2017 at 12:28 AM, Kees Cook wrote: On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote: On 05/16/2017 05:01 AM, Peter Dolding wrote: I could see a case being make for CAP_SYS_TTY_CONFIG. However I still choose to do

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/16/2017 05:01 AM, Peter Dolding wrote: I could see a case being make for CAP_SYS_TTY_CONFIG. However I still choose to do with CAP_SYS_ADMIN because it is already in use in the TIOCSTI ioctl. Matt Brown don't give me existing behaviour.CAP_SYS_ADMIN is overload. The documentation

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/16/2017 05:01 AM, Peter Dolding wrote: I could see a case being make for CAP_SYS_TTY_CONFIG. However I still choose to do with CAP_SYS_ADMIN because it is already in use in the TIOCSTI ioctl. Matt Brown don't give me existing behaviour.CAP_SYS_ADMIN is overload. The documentation

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/15/2017 07:10 PM, Peter Dolding wrote: On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote: O> I'm not implying that my patch is supposed to provide safety for "hundreds of other" issues. I'm looking to provide a way to lock down a single TTY ioctl that has

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/15/2017 07:10 PM, Peter Dolding wrote: On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote: O> I'm not implying that my patch is supposed to provide safety for "hundreds of other" issues. I'm looking to provide a way to lock down a single TTY ioctl that has caused real security issues to

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/10/2017 04:29 PM, Alan Cox wrote: On Fri, 5 May 2017 19:20:16 -0400 Matt Brown <m...@nmatt.com> wrote: This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/10/2017 04:29 PM, Alan Cox wrote: On Fri, 5 May 2017 19:20:16 -0400 Matt Brown wrote: This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Acked-by: Serge Hallyn <se...@hallyn.com> Reviewed-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Matt Brown <m...@nmatt.com> --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 6 ++ include/linux/

[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct

ok <keesc...@chromium.org> Signed-off-by: Matt Brown <m...@nmatt.com> --- drivers/tty/tty_io.c | 2 ++ include/linux/tty.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index e6d1a65..c276814 100644 --- a/drivers/tty/tty_io.c +++ b

[PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Acked-by: Serge Hallyn Reviewed-by: Kees Cook Signed-off-by: Matt Brown --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 6 ++ include/linux/tty.h | 2 ++ kernel/sysctl.c | 12 +++

[PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct

MIN) This combined with the use of user namespace's will allow hardening protections to be built to mitigate container escapes that utilize TTY ioctls such as TIOCSTI. See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256 Acked-by: Serge Hallyn Reviewed-by: Kees Cook Signed-off-by: Matt Br

Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

On 05/03/2017 03:45 PM, Greg KH wrote: On Wed, May 03, 2017 at 12:32:07PM -0700, Kees Cook wrote: On Mon, Apr 24, 2017 at 6:57 AM, Serge E. Hallyn <se...@hallyn.com> wrote: Quoting Matt Brown (m...@nmatt.com): This patch adds struct user_namespace *owner_user_ns to the tty_

Re: [PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

On 05/03/2017 03:45 PM, Greg KH wrote: On Wed, May 03, 2017 at 12:32:07PM -0700, Kees Cook wrote: On Mon, Apr 24, 2017 at 6:57 AM, Serge E. Hallyn wrote: Quoting Matt Brown (m...@nmatt.com): This patch adds struct user_namespace *owner_user_ns to the tty_struct. Then it is set

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 04/26/2017 08:47 AM, One Thousand Gnomes wrote: open() what? As far as I know, for System-V PTYs, there is no path you can open() that will give you the PTY master. Am I missing something? Sorry brain fade - no. If I want to do the equvalent of the TIOCSTI attack then I fork a process

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 04/26/2017 08:47 AM, One Thousand Gnomes wrote: open() what? As far as I know, for System-V PTYs, there is no path you can open() that will give you the PTY master. Am I missing something? Sorry brain fade - no. If I want to do the equvalent of the TIOCSTI attack then I fork a process

[PATCH v5 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Signed-off-by: Matt Brown <m...@nmatt.com> --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 6 ++ include/linux/tty.h | 2 ++ kernel/sysctl.c | 12 security/Kconfi

[PATCH v5 1/2] security: tty: Add owner user namespace to tty_struct

MIN) This combined with the use of user namespace's will allow hardening protections to be built to mitigate container escapes that utilize TTY ioctls such as TIOCSTI. See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256 Signed-off-by: Matt Brown <m...@nmatt.com> --- drivers/tty/tty

[PATCH v5 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Signed-off-by: Matt Brown --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 6 ++ include/linux/tty.h | 2 ++ kernel/sysctl.c | 12 security/Kconfig| 13 +++

[PATCH v5 1/2] security: tty: Add owner user namespace to tty_struct

MIN) This combined with the use of user namespace's will allow hardening protections to be built to mitigate container escapes that utilize TTY ioctls such as TIOCSTI. See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256 Signed-off-by: Matt Brown --- drivers/tty/tty_io.c | 2 ++ include/li

[PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

This patchset introduces the tiocsti_restrict sysctl, whose default is controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. This patch was inspired from GRKERNSEC_HARDEN_TTY. This patch would have prevented

[PATCH v4 2/2] tiocsti-restrict : make TIOCSTI ioctl require CAP_SYS_ADMIN

iginally opened the tty. Signed-off-by: Matt Brown <m...@nmatt.com> --- Documentation/sysctl/kernel.txt | 21 + drivers/tty/tty_io.c| 6 ++ include/linux/tty.h | 2 ++ kernel/sysctl.c | 12 security/Kconfi

[PATCH v4 1/2] tiocsti-restrict : Add owner user namespace to tty_struct

MIN) This combined with the use of user namespace's will allow hardening protections to be built to mitigate container escapes that utilize TTY ioctls such as TIOCSTI. See: https://bugzilla.redhat.com/show_bug.cgi?id=1411256 Signed-off-by: Matt Brown <m...@nmatt.com> --- drivers/tty/tty

  1   2   >