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 inst
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
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 us
is 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
> configuration support.
>
> The
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
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
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
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
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 be
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
>>
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 takin
option and makes
kernel.tpe.gid 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
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
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);
+
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
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 w
e'
2. Attacker on system 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
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 u
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
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 proble
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 difference betwee
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 matt
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
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 against
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
>>>&g
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 pro
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 io
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 the
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. I
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 by
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 if a
>> security measure is being 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
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
er namespace that originally 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
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: Ma
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
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
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 with
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 document
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 ari
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
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
er namespace that originally 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
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: Ma
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On 04/21/2017 01:24 AM, Serge E. Hallyn wrote:
On Fri, Apr 21, 2017 at 01:09:59AM -0400, Matt Brown wrote:
On 04/20/2017 01:41 PM, Serge E. Hallyn wrote:
Quoting m...@nmatt.com (m...@nmatt.com):
On 2017-04-20 11:19, Serge E. Hallyn wrote:
Quoting Matt Brown (m...@nmatt.com):
On 04/19/2017
On 04/20/2017 01:41 PM, Serge E. Hallyn wrote:
Quoting m...@nmatt.com (m...@nmatt.com):
On 2017-04-20 11:19, Serge E. Hallyn wrote:
Quoting Matt Brown (m...@nmatt.com):
On 04/19/2017 07:53 PM, Serge E. Hallyn wrote:
Quoting Matt Brown (m...@nmatt.com):
On 04/19/2017 12:58 AM, Serge E
On 04/19/2017 07:53 PM, Serge E. Hallyn wrote:
Quoting Matt Brown (m...@nmatt.com):
On 04/19/2017 12:58 AM, Serge E. Hallyn wrote:
On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:
This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity
project in-kernel.
This
On 04/19/2017 07:18 AM, James Morris wrote:
On Tue, 18 Apr 2017, Matt Brown wrote:
This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity
project in-kernel.
It seems like an ugly hack to an ugly feature (CAP_SYS_ADMIN barely makes
sense here), and rather than sprinkling
On 04/19/2017 01:20 AM, Kees Cook wrote:
On Tue, Apr 18, 2017 at 9:58 PM, Serge E. Hallyn wrote:
On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:
This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity
project in-kernel.
This will create the Kconfig
On 04/19/2017 12:58 AM, Serge E. Hallyn wrote:
On Tue, Apr 18, 2017 at 11:45:26PM -0400, Matt Brown wrote:
This patch reproduces GRKERNSEC_HARDEN_TTY functionality from the grsecurity
project in-kernel.
This will create the Kconfig SECURITY_TIOCSTI_RESTRICT and the corresponding
sysctl
compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.
This is also an excellent writeup about the issue:
<http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeE
On 04/17/2017 02:50 AM, Greg KH wrote:
On Mon, Apr 17, 2017 at 02:07:03AM -0400, Matt Brown wrote:
adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow
the user to restrict unprivileged command injection using TIOCSTI
tty ioctls
"unpriviledged command injection"? T
On 04/17/2017 10:18 AM, Jann Horn wrote:
On Mon, Apr 17, 2017 at 8:53 AM, Greg KH wrote:
On Mon, Apr 17, 2017 at 02:07:05AM -0400, Matt Brown wrote:
this patch depends on patch 1 and 2
enforces restrictions on unprivileged users injecting commands
into other processes in the same tty session
adding extern variable tiocsti_restrict to allow it to be included
in sysctl
Signed-off-by: Matt Brown
---
include/linux/tty.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 1017e904..7011102 100644
--- a/include/linux/tty.h
+++ b/include
The following patchset reproduces GRKERNSEC_HARDEN_TTY functionality from the
grsecurity project in-kernel. The purpose of this feature is to restrict
unprivileged users from injecting commands into other processes in the same tty
session by using the TIOCSTI ioctl.
It creates the kernel config
adding the kernel config SECURITY_TIOCSTI_RESTRICT in order to allow
the user to restrict unprivileged command injection using TIOCSTI
tty ioctls
Signed-off-by: Matt Brown
---
security/Kconfig | 12
1 file changed, 12 insertions(+)
diff --git a/security/Kconfig b/security/Kconfig
this patch depends on patch 1 and 2
enforces restrictions on unprivileged users injecting commands
into other processes in the same tty session using the TIOCSTI ioctl
Signed-off-by: Matt Brown
---
drivers/tty/tty_io.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/tty
this patch depends on patches 1, 2 and 3
Allow CONFIG_SECURITY_TIOCSTI_RESTRICT to be controlled via sysctl
Signed-off-by: Matt Brown
---
kernel/sysctl.c | 12
1 file changed, 12 insertions(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index acf0a5a..68d1363 100644
--- a
73 matches
Mail list logo
