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 <m...@nmatt.com>
---
security/Kconfig | 12
1 file changed, 12 insertions(+)
diff --git a/security/Kco
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 <m...@nmatt.com>
---
drivers/tty/tty_io.c | 4
1 file changed, 4 insertions(+)
diff
this patch depends on patches 1, 2 and 3
Allow CONFIG_SECURITY_TIOCSTI_RESTRICT to be controlled via sysctl
Signed-off-by: Matt Brown <m...@nmatt.com>
---
kernel/sysctl.c | 12
1 file changed, 12 insertions(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index acf0a5a..6
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
adding extern variable tiocsti_restrict to allow it to be included
in sysctl
Signed-off-by: Matt Brown <m...@nmatt.com>
---
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
On 04/17/2017 10:18 AM, Jann Horn wrote:
On Mon, Apr 17, 2017 at 8:53 AM, Greg KH <gre...@linuxfoundation.org> 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
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/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/19/2017 01:20 AM, Kees Cook wrote:
On Tue, Apr 18, 2017 at 9:58 PM, Serge E. Hallyn <se...@hallyn.com> 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
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 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
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
On 04/23/2017 01:02 PM, Jann Horn wrote:
On Sun, Apr 23, 2017 at 9:24 AM, Matt Brown <m...@nmatt.com> 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 capa
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
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
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 opened
the tty.
Sign
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
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
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
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 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
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 opened
the tty.
Sign
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
ult. 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/TtyPushbackPrivilegeEscalation/>
Sign
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
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
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
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
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
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
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 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,
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_
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
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
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
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
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 <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
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
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
;>> * 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
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
>>
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
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
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
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
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
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
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
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 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
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
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'
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
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
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
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
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
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 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
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
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
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 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
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:
>>>>>>
>>>>>
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
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/
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
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/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.
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
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
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
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
:
> 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
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 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
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
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'
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
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
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
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
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
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 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
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
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
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
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 +++
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
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
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
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
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.
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
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
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.
1 - 100 of 146 matches
Mail list logo