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

2017-04-23 Thread Matt Brown
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 | 1 + inclu

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

2017-04-23 Thread Matt Brown
indeed shared over privilege boundaries. This is also an excellent writeup about the issue: <http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/> When user namespaces are in use, the check for the capability CAP_SYS_ADMIN is done against the user namespace that originally o

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

2017-04-23 Thread Matt Brown
On 04/23/2017 01:02 PM, Jann Horn wrote: On Sun, Apr 23, 2017 at 9:24 AM, Matt Brown wrote: This patch adds struct user_namespace *owner_user_ns to the tty_struct. Then it is set to current_user_ns() in the alloc_tty_struct function. This is done to facilitate capability checks against the

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

2017-04-23 Thread Matt Brown
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 h

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

2017-04-23 Thread Matt Brown
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 | 4 inclu

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

2017-04-23 Thread Matt Brown
indeed shared over privilege boundaries. This is also an excellent writeup about the issue: <http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/> When user namespaces are in use, the check for the capability CAP_SYS_ADMIN is done against the user namespace that originally o

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

2017-04-23 Thread Matt Brown
On 04/23/2017 09:09 PM, 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 to current_user_ns() in the alloc_tty_struct function. This is done to facilitate capability checks against the original

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

2017-04-23 Thread Matt Brown
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 h

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

2017-04-23 Thread Matt Brown
er namespace that originally 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

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

2017-04-23 Thread Matt Brown
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 ++ inclu

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

2017-04-24 Thread Matt Brown
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 h

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

2017-04-24 Thread Matt Brown
er namespace that originally 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

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

2017-04-24 Thread Matt Brown
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 ++ inclu

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

2017-04-26 Thread Matt Brown
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 and

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

2017-05-03 Thread Matt Brown
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 to