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

[kbuild test robot]

Hi Matt,

[auto build test WARNING on security/next]
[also build test WARNING on v4.12-rc5 next-20170615]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matt-Brown/Add-Trusted-Path-Execution-as-a-stackable-LSM/20170609-115004
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> security/tpe/tpe_lsm.c:45:5: sparse: symbol 'print_tpe_error' was not 
>> declared. Should it be static?
>> security/tpe/tpe_lsm.c:128:5: sparse: symbol 'tpe_mmap_file' was not 
>> declared. Should it be static?
>> security/tpe/tpe_lsm.c:137:5: sparse: symbol 'tpe_file_mprotect' was not 
>> declared. Should it be static?
>> security/tpe/tpe_lsm.c:160:17: sparse: symbol 'tpe_sysctl_path' was not 
>> declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

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

[kbuild test robot]

Hi Matt,

[auto build test WARNING on security/next]
[also build test WARNING on v4.12-rc5 next-20170615]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matt-Brown/Add-Trusted-Path-Execution-as-a-stackable-LSM/20170609-115004
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> security/tpe/tpe_lsm.c:45:5: sparse: symbol 'print_tpe_error' was not 
>> declared. Should it be static?
>> security/tpe/tpe_lsm.c:128:5: sparse: symbol 'tpe_mmap_file' was not 
>> declared. Should it be static?
>> security/tpe/tpe_lsm.c:137:5: sparse: symbol 'tpe_file_mprotect' was not 
>> declared. Should it be static?
>> security/tpe/tpe_lsm.c:160:17: sparse: symbol 'tpe_sysctl_path' was not 
>> declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

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

[Mimi Zohar]

On Fri, 2017-06-09 at 09:18 -0400, Matt Brown wrote:
> 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:
> >>*  Can be bypassed by interpreted languages such as python. You can 
> >> run
> >>   malicious code by doing: python -c 'evil code'
> >
> > What's the recommendation for people interested in using TPE but
> > having interpreters installed?
> >
> 
>  If you don't need a given interpreter installed, uninstall it. While
>  this is common sense system hardening it especially would make a
>  difference under the TPE threat model.
> 
>  I don't have a knock down answer for this. Interpreters are a hard
>  problem for TPE.
> >>>
> >>> You might be interested in the minor LSM named "shebang", that I
> >>> posted as a proof of concept back in January, which restricts the
> >>> python interactive prompt/interpreter, but allows the scripts
> >>> themselves to be executed.
> >>
> >> https://patchwork.kernel.org/patch/9547405/
> >>
> >> Maybe these could be merged and the interpreter string could be made
> >> into a configurable list?
> > 
> > I updated shebang, but didn't bother to post it, as nobody seemed to
> > be interested at the time.  The updated version already has support
> > for the configurable list. Re-posting ...
> > 
> 
> That would be awesome. I think it's the perfect complement to TPE as it
> protects a key hole in its current threat model.

Hm, I hadn't looked at it in since January.  It still needs to be
cleaned up and expanded a bit.  The original version used a pathname
for identifying the interpreter.  This version converts the list of
pathnames to a set of inodes, which is better, but now requires a
method for updating the inode number after a software update.

Please feel free to expand on it or re-use whatever you like.

Mimi

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

[Mimi Zohar]

On Fri, 2017-06-09 at 09:18 -0400, Matt Brown wrote:
> 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:
> >>*  Can be bypassed by interpreted languages such as python. You can 
> >> run
> >>   malicious code by doing: python -c 'evil code'
> >
> > What's the recommendation for people interested in using TPE but
> > having interpreters installed?
> >
> 
>  If you don't need a given interpreter installed, uninstall it. While
>  this is common sense system hardening it especially would make a
>  difference under the TPE threat model.
> 
>  I don't have a knock down answer for this. Interpreters are a hard
>  problem for TPE.
> >>>
> >>> You might be interested in the minor LSM named "shebang", that I
> >>> posted as a proof of concept back in January, which restricts the
> >>> python interactive prompt/interpreter, but allows the scripts
> >>> themselves to be executed.
> >>
> >> https://patchwork.kernel.org/patch/9547405/
> >>
> >> Maybe these could be merged and the interpreter string could be made
> >> into a configurable list?
> > 
> > I updated shebang, but didn't bother to post it, as nobody seemed to
> > be interested at the time.  The updated version already has support
> > for the configurable list. Re-posting ...
> > 
> 
> That would be awesome. I think it's the perfect complement to TPE as it
> protects a key hole in its current threat model.

Hm, I hadn't looked at it in since January.  It still needs to be
cleaned up and expanded a bit.  The original version used a pathname
for identifying the interpreter.  This version converts the list of
pathnames to a set of inodes, which is better, but now requires a
method for updating the inode number after a software update.

Please feel free to expand on it or re-use whatever you like.

Mimi

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

[Matt Brown]

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:
>>*  Can be bypassed by interpreted languages such as python. You can 
>> run
>>   malicious code by doing: python -c 'evil code'
>
> What's the recommendation for people interested in using TPE but
> having interpreters installed?
>

 If you don't need a given interpreter installed, uninstall it. While
 this is common sense system hardening it especially would make a
 difference under the TPE threat model.

 I don't have a knock down answer for this. Interpreters are a hard
 problem for TPE.
>>>
>>> You might be interested in the minor LSM named "shebang", that I
>>> posted as a proof of concept back in January, which restricts the
>>> python interactive prompt/interpreter, but allows the scripts
>>> themselves to be executed.
>>
>> https://patchwork.kernel.org/patch/9547405/
>>
>> Maybe these could be merged and the interpreter string could be made
>> into a configurable list?
> 
> I updated shebang, but didn't bother to post it, as nobody seemed to
> be interested at the time.  The updated version already has support
> for the configurable list. Re-posting ...
> 

That would be awesome. I think it's the perfect complement to TPE as it
protects a key hole in its current threat model.

Matt

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

[Matt Brown]

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:
>>*  Can be bypassed by interpreted languages such as python. You can 
>> run
>>   malicious code by doing: python -c 'evil code'
>
> What's the recommendation for people interested in using TPE but
> having interpreters installed?
>

 If you don't need a given interpreter installed, uninstall it. While
 this is common sense system hardening it especially would make a
 difference under the TPE threat model.

 I don't have a knock down answer for this. Interpreters are a hard
 problem for TPE.
>>>
>>> You might be interested in the minor LSM named "shebang", that I
>>> posted as a proof of concept back in January, which restricts the
>>> python interactive prompt/interpreter, but allows the scripts
>>> themselves to be executed.
>>
>> https://patchwork.kernel.org/patch/9547405/
>>
>> Maybe these could be merged and the interpreter string could be made
>> into a configurable list?
> 
> I updated shebang, but didn't bother to post it, as nobody seemed to
> be interested at the time.  The updated version already has support
> for the configurable list. Re-posting ...
> 

That would be awesome. I think it's the perfect complement to TPE as it
protects a key hole in its current threat model.

Matt

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

[Mimi Zohar]

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:
> >> >>*  Can be bypassed by interpreted languages such as python. You can 
> >> >> run
> >> >>   malicious code by doing: python -c 'evil code'
> >> >
> >> > What's the recommendation for people interested in using TPE but
> >> > having interpreters installed?
> >> >
> >>
> >> If you don't need a given interpreter installed, uninstall it. While
> >> this is common sense system hardening it especially would make a
> >> difference under the TPE threat model.
> >>
> >> I don't have a knock down answer for this. Interpreters are a hard
> >> problem for TPE.
> >
> > You might be interested in the minor LSM named "shebang", that I
> > posted as a proof of concept back in January, which restricts the
> > python interactive prompt/interpreter, but allows the scripts
> > themselves to be executed.
> 
> https://patchwork.kernel.org/patch/9547405/
> 
> Maybe these could be merged and the interpreter string could be made
> into a configurable list?

I updated shebang, but didn't bother to post it, as nobody seemed to
be interested at the time.  The updated version already has support
for the configurable list. Re-posting ...

Mimi

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

[Mimi Zohar]

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:
> >> >>*  Can be bypassed by interpreted languages such as python. You can 
> >> >> run
> >> >>   malicious code by doing: python -c 'evil code'
> >> >
> >> > What's the recommendation for people interested in using TPE but
> >> > having interpreters installed?
> >> >
> >>
> >> If you don't need a given interpreter installed, uninstall it. While
> >> this is common sense system hardening it especially would make a
> >> difference under the TPE threat model.
> >>
> >> I don't have a knock down answer for this. Interpreters are a hard
> >> problem for TPE.
> >
> > You might be interested in the minor LSM named "shebang", that I
> > posted as a proof of concept back in January, which restricts the
> > python interactive prompt/interpreter, but allows the scripts
> > themselves to be executed.
> 
> https://patchwork.kernel.org/patch/9547405/
> 
> Maybe these could be merged and the interpreter string could be made
> into a configurable list?

I updated shebang, but didn't bother to post it, as nobody seemed to
be interested at the time.  The updated version already has support
for the configurable list. Re-posting ...

Mimi

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

[Matt Brown]

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 can run
>   malicious code by doing: python -c 'evil code'

 What's the recommendation for people interested in using TPE but
 having interpreters installed?

>>>
>>> If you don't need a given interpreter installed, uninstall it. While
>>> this is common sense system hardening it especially would make a
>>> difference under the TPE threat model.
>>>
>>> I don't have a knock down answer for this. Interpreters are a hard
>>> problem for TPE.
>>
>> You might be interested in the minor LSM named "shebang", that I
>> posted as a proof of concept back in January, which restricts the
>> python interactive prompt/interpreter, but allows the scripts
>> themselves to be executed.
> 
> https://patchwork.kernel.org/patch/9547405/
> 
> Maybe these could be merged and the interpreter string could be made
> into a configurable list?
> 

Yes this looks promising. I'll look into integrating this.

Matt

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

[Matt Brown]

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 can run
>   malicious code by doing: python -c 'evil code'

 What's the recommendation for people interested in using TPE but
 having interpreters installed?

>>>
>>> If you don't need a given interpreter installed, uninstall it. While
>>> this is common sense system hardening it especially would make a
>>> difference under the TPE threat model.
>>>
>>> I don't have a knock down answer for this. Interpreters are a hard
>>> problem for TPE.
>>
>> You might be interested in the minor LSM named "shebang", that I
>> posted as a proof of concept back in January, which restricts the
>> python interactive prompt/interpreter, but allows the scripts
>> themselves to be executed.
> 
> https://patchwork.kernel.org/patch/9547405/
> 
> Maybe these could be merged and the interpreter string could be made
> into a configurable list?
> 

Yes this looks promising. I'll look into integrating this.

Matt

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

[Kees Cook]

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 can run
>> >>   malicious code by doing: python -c 'evil code'
>> >
>> > What's the recommendation for people interested in using TPE but
>> > having interpreters installed?
>> >
>>
>> If you don't need a given interpreter installed, uninstall it. While
>> this is common sense system hardening it especially would make a
>> difference under the TPE threat model.
>>
>> I don't have a knock down answer for this. Interpreters are a hard
>> problem for TPE.
>
> You might be interested in the minor LSM named "shebang", that I
> posted as a proof of concept back in January, which restricts the
> python interactive prompt/interpreter, but allows the scripts
> themselves to be executed.

https://patchwork.kernel.org/patch/9547405/

Maybe these could be merged and the interpreter string could be made
into a configurable list?

-Kees

-- 
Kees Cook
Pixel Security

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

[Kees Cook]

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 can run
>> >>   malicious code by doing: python -c 'evil code'
>> >
>> > What's the recommendation for people interested in using TPE but
>> > having interpreters installed?
>> >
>>
>> If you don't need a given interpreter installed, uninstall it. While
>> this is common sense system hardening it especially would make a
>> difference under the TPE threat model.
>>
>> I don't have a knock down answer for this. Interpreters are a hard
>> problem for TPE.
>
> You might be interested in the minor LSM named "shebang", that I
> posted as a proof of concept back in January, which restricts the
> python interactive prompt/interpreter, but allows the scripts
> themselves to be executed.

https://patchwork.kernel.org/patch/9547405/

Maybe these could be merged and the interpreter string could be made
into a configurable list?

-Kees

-- 
Kees Cook
Pixel Security

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

[Mimi Zohar]

On Thu, 2017-06-08 at 23:50 -0400, Matt Brown wrote:
> >>
> >> *  Issues:
> >>    *  Can be bypassed by interpreted languages such as python. You can run
> >>   malicious code by doing: python -c 'evil code'
> >
> > What's the recommendation for people interested in using TPE but
> > having interpreters installed?
> >
> 
> If you don't need a given interpreter installed, uninstall it. While
> this is common sense system hardening it especially would make a
> difference under the TPE threat model.
> 
> I don't have a knock down answer for this. Interpreters are a hard
> problem for TPE.

You might be interested in the minor LSM named "shebang", that I
posted as a proof of concept back in January, which restricts the
python interactive prompt/interpreter, but allows the scripts
themselves to be executed.

Mimi

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

[Mimi Zohar]

On Thu, 2017-06-08 at 23:50 -0400, Matt Brown wrote:
> >>
> >> *  Issues:
> >>    *  Can be bypassed by interpreted languages such as python. You can run
> >>   malicious code by doing: python -c 'evil code'
> >
> > What's the recommendation for people interested in using TPE but
> > having interpreters installed?
> >
> 
> If you don't need a given interpreter installed, uninstall it. While
> this is common sense system hardening it especially would make a
> difference under the TPE threat model.
> 
> I don't have a knock down answer for this. Interpreters are a hard
> problem for TPE.

You might be interested in the minor LSM named "shebang", that I
posted as a proof of concept back in January, which restricts the
python interactive prompt/interpreter, but allows the scripts
themselves to be executed.

Mimi

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

[Matt Brown]

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 Spengler's implementation of TPE were made to
turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
Also, a new denial logging function was used to simplify printing messages
to the kernel log. Additionally, mmap and mprotect restrictions were
taken from Corey Henderson's tpe-lkm project and implemented using the
LSM hooks mmap_file and file_mprotect.

Trusted Path Execution is not a new idea:

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
| users home directory is not trusted, nor is /tmp.

To be clear, Trusted Path Execution is no replacement for a MAC system
like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough
without requiring a userland utility to configure policies. The fact
that TPE only requires the user to turn on a few sysctl options lowers
the barrier to implementing a security framework substantially.

Threat Models:

1. Attacker on system executing exploit on system vulnerability

*  If attacker uses a binary as a part of their system exploit, TPE can
   frustrate their efforts

*  This protection can be more effective when an attacker does not yet
   have an interactive shell on a system

*  Issues:
   *  Can be bypassed by interpreted languages such as python. You can run
  malicious code by doing: python -c 'evil code'


What's the recommendation for people interested in using TPE but
having interpreters installed?



If you don't need a given interpreter installed, uninstall it. While
this is common sense system hardening it especially would make a
difference under the TPE threat model.

I don't have a knock down answer for this. Interpreters are a hard
problem for TPE.



2. Attacker on system replaces binary used by a privileged user with a
   malicious one

*  This situation arises when the administrator of a system leaves a
   binary as world writable.

*  TPE is very effective against this threat model

This Trusted Path Execution implementation introduces the following
Kconfig options and sysctls. The Kconfig text and sysctl options are
taken heavily from Brad Spengler's implementation. Some extra sysctl
options were taken from Corey Henderson's implementation.

CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)

default: n

This option enables Trusted Path Execution. TPE blocks *untrusted*
users from executing files that meet the following conditions:

* file is not in a root-owned directory
* file is writable by a user other than root

NOTE: By default root is not restricted by TPE.

CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)

default: 0

This option defines a group id that, by default, is the trusted group.
If a user is not trusted then it has the checks described in
CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
checks are not applied. You can disable the trusted gid option by
setting it to 0. This makes all non-root users untrusted.

CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict)

default: n

This option applies another set of restrictions to all non-root users
even if they are trusted. This only allows execution under the
following conditions:

* file is in a directory owned by the user that is not group or
  world-writable
* file is in a directory owned by root and writable only by root

CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root)

default: n

This option applies all enabled TPE restrictions to root.

CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid)

default: n

This option reverses the trust logic of the gid 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|   5 +
 include/linux/lsm_hooks.h  |   5 +
 security/Kconfig   |   1 +
 security/Makefile  |   2 +
 security/security.c|   1 +
 security/tpe/Kconfig   |  64 
 security/tpe/Makefile  |   3 +
 security/tpe/tpe_lsm.c | 218 +
 9 files changed, 358 insertions(+)
 create mode 100644 Documentation/security/tpe.txt
 create mode 100644 security/tpe/Kconfig
 create mode 100644 security/tpe/Makefile
 create mode 100644 security/tpe/tpe_lsm.c

diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt
new file 

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

[Matt Brown]

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 Spengler's implementation of TPE were made to
turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
Also, a new denial logging function was used to simplify printing messages
to the kernel log. Additionally, mmap and mprotect restrictions were
taken from Corey Henderson's tpe-lkm project and implemented using the
LSM hooks mmap_file and file_mprotect.

Trusted Path Execution is not a new idea:

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
| users home directory is not trusted, nor is /tmp.

To be clear, Trusted Path Execution is no replacement for a MAC system
like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough
without requiring a userland utility to configure policies. The fact
that TPE only requires the user to turn on a few sysctl options lowers
the barrier to implementing a security framework substantially.

Threat Models:

1. Attacker on system executing exploit on system vulnerability

*  If attacker uses a binary as a part of their system exploit, TPE can
   frustrate their efforts

*  This protection can be more effective when an attacker does not yet
   have an interactive shell on a system

*  Issues:
   *  Can be bypassed by interpreted languages such as python. You can run
  malicious code by doing: python -c 'evil code'


What's the recommendation for people interested in using TPE but
having interpreters installed?



If you don't need a given interpreter installed, uninstall it. While
this is common sense system hardening it especially would make a
difference under the TPE threat model.

I don't have a knock down answer for this. Interpreters are a hard
problem for TPE.



2. Attacker on system replaces binary used by a privileged user with a
   malicious one

*  This situation arises when the administrator of a system leaves a
   binary as world writable.

*  TPE is very effective against this threat model

This Trusted Path Execution implementation introduces the following
Kconfig options and sysctls. The Kconfig text and sysctl options are
taken heavily from Brad Spengler's implementation. Some extra sysctl
options were taken from Corey Henderson's implementation.

CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)

default: n

This option enables Trusted Path Execution. TPE blocks *untrusted*
users from executing files that meet the following conditions:

* file is not in a root-owned directory
* file is writable by a user other than root

NOTE: By default root is not restricted by TPE.

CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)

default: 0

This option defines a group id that, by default, is the trusted group.
If a user is not trusted then it has the checks described in
CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
checks are not applied. You can disable the trusted gid option by
setting it to 0. This makes all non-root users untrusted.

CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict)

default: n

This option applies another set of restrictions to all non-root users
even if they are trusted. This only allows execution under the
following conditions:

* file is in a directory owned by the user that is not group or
  world-writable
* file is in a directory owned by root and writable only by root

CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root)

default: n

This option applies all enabled TPE restrictions to root.

CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid)

default: n

This option reverses the trust logic of the gid 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|   5 +
 include/linux/lsm_hooks.h  |   5 +
 security/Kconfig   |   1 +
 security/Makefile  |   2 +
 security/security.c|   1 +
 security/tpe/Kconfig   |  64 
 security/tpe/Makefile  |   3 +
 security/tpe/tpe_lsm.c | 218 +
 9 files changed, 358 insertions(+)
 create mode 100644 Documentation/security/tpe.txt
 create mode 100644 security/tpe/Kconfig
 create mode 100644 security/tpe/Makefile
 create mode 100644 security/tpe/tpe_lsm.c

diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt
new file mode 100644
index 

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

[Kees Cook]

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 Spengler's implementation of TPE were made to
> turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
> Also, a new denial logging function was used to simplify printing messages
> to the kernel log. Additionally, mmap and mprotect restrictions were
> taken from Corey Henderson's tpe-lkm project and implemented using the
> LSM hooks mmap_file and file_mprotect.
>
> Trusted Path Execution is not a new idea:
>
> 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
> | users home directory is not trusted, nor is /tmp.
>
> To be clear, Trusted Path Execution is no replacement for a MAC system
> like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough
> without requiring a userland utility to configure policies. The fact
> that TPE only requires the user to turn on a few sysctl options lowers
> the barrier to implementing a security framework substantially.
>
> Threat Models:
>
> 1. Attacker on system executing exploit on system vulnerability
>
> *  If attacker uses a binary as a part of their system exploit, TPE can
>frustrate their efforts
>
> *  This protection can be more effective when an attacker does not yet
>have an interactive shell on a system
>
> *  Issues:
>*  Can be bypassed by interpreted languages such as python. You can run
>   malicious code by doing: python -c 'evil code'

What's the recommendation for people interested in using TPE but
having interpreters installed?

>
> 2. Attacker on system replaces binary used by a privileged user with a
>malicious one
>
> *  This situation arises when the administrator of a system leaves a
>binary as world writable.
>
> *  TPE is very effective against this threat model
>
> This Trusted Path Execution implementation introduces the following
> Kconfig options and sysctls. The Kconfig text and sysctl options are
> taken heavily from Brad Spengler's implementation. Some extra sysctl
> options were taken from Corey Henderson's implementation.
>
> CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)
>
> default: n
>
> This option enables Trusted Path Execution. TPE blocks *untrusted*
> users from executing files that meet the following conditions:
>
> * file is not in a root-owned directory
> * file is writable by a user other than root
>
> NOTE: By default root is not restricted by TPE.
>
> CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)
>
> default: 0
>
> This option defines a group id that, by default, is the trusted group.
> If a user is not trusted then it has the checks described in
> CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
> checks are not applied. You can disable the trusted gid option by
> setting it to 0. This makes all non-root users untrusted.
>
> CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict)
>
> default: n
>
> This option applies another set of restrictions to all non-root users
> even if they are trusted. This only allows execution under the
> following conditions:
>
> * file is in a directory owned by the user that is not group or
>   world-writable
> * file is in a directory owned by root and writable only by root
>
> CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root)
>
> default: n
>
> This option applies all enabled TPE restrictions to root.
>
> CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid)
>
> default: n
>
> This option reverses the trust logic of the gid 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|   5 +
>  include/linux/lsm_hooks.h  |   5 +
>  security/Kconfig   |   1 +
>  security/Makefile  |   2 +
>  security/security.c|   1 +
>  security/tpe/Kconfig   |  64 
>  security/tpe/Makefile  |   3 +
>  security/tpe/tpe_lsm.c | 218 
> +
>  9 files changed, 358 insertions(+)
>  create mode 100644 Documentation/security/tpe.txt
>  create mode 100644 security/tpe/Kconfig
>  create mode 100644 security/tpe/Makefile
>  create mode 100644 security/tpe/tpe_lsm.c
>
> diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt
> new file mode 100644
> index 000..226afcc
> --- /dev/null
> +++ b/Documentation/security/tpe.txt
> @@ 

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

[Kees Cook]

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 Spengler's implementation of TPE were made to
> turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
> Also, a new denial logging function was used to simplify printing messages
> to the kernel log. Additionally, mmap and mprotect restrictions were
> taken from Corey Henderson's tpe-lkm project and implemented using the
> LSM hooks mmap_file and file_mprotect.
>
> Trusted Path Execution is not a new idea:
>
> 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
> | users home directory is not trusted, nor is /tmp.
>
> To be clear, Trusted Path Execution is no replacement for a MAC system
> like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough
> without requiring a userland utility to configure policies. The fact
> that TPE only requires the user to turn on a few sysctl options lowers
> the barrier to implementing a security framework substantially.
>
> Threat Models:
>
> 1. Attacker on system executing exploit on system vulnerability
>
> *  If attacker uses a binary as a part of their system exploit, TPE can
>frustrate their efforts
>
> *  This protection can be more effective when an attacker does not yet
>have an interactive shell on a system
>
> *  Issues:
>*  Can be bypassed by interpreted languages such as python. You can run
>   malicious code by doing: python -c 'evil code'

What's the recommendation for people interested in using TPE but
having interpreters installed?

>
> 2. Attacker on system replaces binary used by a privileged user with a
>malicious one
>
> *  This situation arises when the administrator of a system leaves a
>binary as world writable.
>
> *  TPE is very effective against this threat model
>
> This Trusted Path Execution implementation introduces the following
> Kconfig options and sysctls. The Kconfig text and sysctl options are
> taken heavily from Brad Spengler's implementation. Some extra sysctl
> options were taken from Corey Henderson's implementation.
>
> CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)
>
> default: n
>
> This option enables Trusted Path Execution. TPE blocks *untrusted*
> users from executing files that meet the following conditions:
>
> * file is not in a root-owned directory
> * file is writable by a user other than root
>
> NOTE: By default root is not restricted by TPE.
>
> CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)
>
> default: 0
>
> This option defines a group id that, by default, is the trusted group.
> If a user is not trusted then it has the checks described in
> CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
> checks are not applied. You can disable the trusted gid option by
> setting it to 0. This makes all non-root users untrusted.
>
> CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict)
>
> default: n
>
> This option applies another set of restrictions to all non-root users
> even if they are trusted. This only allows execution under the
> following conditions:
>
> * file is in a directory owned by the user that is not group or
>   world-writable
> * file is in a directory owned by root and writable only by root
>
> CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root)
>
> default: n
>
> This option applies all enabled TPE restrictions to root.
>
> CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid)
>
> default: n
>
> This option reverses the trust logic of the gid 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|   5 +
>  include/linux/lsm_hooks.h  |   5 +
>  security/Kconfig   |   1 +
>  security/Makefile  |   2 +
>  security/security.c|   1 +
>  security/tpe/Kconfig   |  64 
>  security/tpe/Makefile  |   3 +
>  security/tpe/tpe_lsm.c | 218 
> +
>  9 files changed, 358 insertions(+)
>  create mode 100644 Documentation/security/tpe.txt
>  create mode 100644 security/tpe/Kconfig
>  create mode 100644 security/tpe/Makefile
>  create mode 100644 security/tpe/tpe_lsm.c
>
> diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt
> new file mode 100644
> index 000..226afcc
> --- /dev/null
> +++ b/Documentation/security/tpe.txt
> @@ -0,0 +1,59 @@
> [...]

Yes, 

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

[Matt Brown]

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 Spengler's implementation of TPE were made to
turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
Also, a new denial logging function was used to simplify printing messages
to the kernel log. Additionally, mmap and mprotect restrictions were
taken from Corey Henderson's tpe-lkm project and implemented using the
LSM hooks mmap_file and file_mprotect.

Trusted Path Execution is not a new idea:

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
| users home directory is not trusted, nor is /tmp.

To be clear, Trusted Path Execution is no replacement for a MAC system
like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough
without requiring a userland utility to configure policies. The fact
that TPE only requires the user to turn on a few sysctl options lowers
the barrier to implementing a security framework substantially.

Threat Models:

1. Attacker on system executing exploit on system vulnerability

*  If attacker uses a binary as a part of their system exploit, TPE can
   frustrate their efforts

*  This protection can be more effective when an attacker does not yet
   have an interactive shell on a system

*  Issues:
   *  Can be bypassed by interpreted languages such as python. You can run
  malicious code by doing: python -c 'evil code'

2. Attacker on system replaces binary used by a privileged user with a
   malicious one

*  This situation arises when the administrator of a system leaves a
   binary as world writable.

*  TPE is very effective against this threat model

This Trusted Path Execution implementation introduces the following
Kconfig options and sysctls. The Kconfig text and sysctl options are
taken heavily from Brad Spengler's implementation. Some extra sysctl
options were taken from Corey Henderson's implementation.

CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)

default: n

This option enables Trusted Path Execution. TPE blocks *untrusted*
users from executing files that meet the following conditions:

* file is not in a root-owned directory
* file is writable by a user other than root

NOTE: By default root is not restricted by TPE.

CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)

default: 0

This option defines a group id that, by default, is the trusted group.
If a user is not trusted then it has the checks described in
CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
checks are not applied. You can disable the trusted gid option by
setting it to 0. This makes all non-root users untrusted.

CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict)

default: n

This option applies another set of restrictions to all non-root users
even if they are trusted. This only allows execution under the
following conditions:

* file is in a directory owned by the user that is not group or
  world-writable
* file is in a directory owned by root and writable only by root

CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root)

default: n

This option applies all enabled TPE restrictions to root.

CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid)

default: n

This option reverses the trust logic of the gid 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|   5 +
 include/linux/lsm_hooks.h  |   5 +
 security/Kconfig   |   1 +
 security/Makefile  |   2 +
 security/security.c|   1 +
 security/tpe/Kconfig   |  64 
 security/tpe/Makefile  |   3 +
 security/tpe/tpe_lsm.c | 218 +
 9 files changed, 358 insertions(+)
 create mode 100644 Documentation/security/tpe.txt
 create mode 100644 security/tpe/Kconfig
 create mode 100644 security/tpe/Makefile
 create mode 100644 security/tpe/tpe_lsm.c

diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt
new file mode 100644
index 000..226afcc
--- /dev/null
+++ b/Documentation/security/tpe.txt
@@ -0,0 +1,59 @@
+Trusted Path Execution is a Linux Security Module that generally requires
+programs to be run from a trusted path. A trusted path is one that is owned by
+root and is not group/world writable. This prevents an attacker from executing
+their own malicious binaries from an unprivileged user on the system. This
+feature is enabled with CONFIG_SECURITY_TPE. When 

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

[Matt Brown]

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 Spengler's implementation of TPE were made to
turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
Also, a new denial logging function was used to simplify printing messages
to the kernel log. Additionally, mmap and mprotect restrictions were
taken from Corey Henderson's tpe-lkm project and implemented using the
LSM hooks mmap_file and file_mprotect.

Trusted Path Execution is not a new idea:

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
| users home directory is not trusted, nor is /tmp.

To be clear, Trusted Path Execution is no replacement for a MAC system
like SELinux, SMACK, or AppArmor. This LSM is designed to be good enough
without requiring a userland utility to configure policies. The fact
that TPE only requires the user to turn on a few sysctl options lowers
the barrier to implementing a security framework substantially.

Threat Models:

1. Attacker on system executing exploit on system vulnerability

*  If attacker uses a binary as a part of their system exploit, TPE can
   frustrate their efforts

*  This protection can be more effective when an attacker does not yet
   have an interactive shell on a system

*  Issues:
   *  Can be bypassed by interpreted languages such as python. You can run
  malicious code by doing: python -c 'evil code'

2. Attacker on system replaces binary used by a privileged user with a
   malicious one

*  This situation arises when the administrator of a system leaves a
   binary as world writable.

*  TPE is very effective against this threat model

This Trusted Path Execution implementation introduces the following
Kconfig options and sysctls. The Kconfig text and sysctl options are
taken heavily from Brad Spengler's implementation. Some extra sysctl
options were taken from Corey Henderson's implementation.

CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)

default: n

This option enables Trusted Path Execution. TPE blocks *untrusted*
users from executing files that meet the following conditions:

* file is not in a root-owned directory
* file is writable by a user other than root

NOTE: By default root is not restricted by TPE.

CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)

default: 0

This option defines a group id that, by default, is the trusted group.
If a user is not trusted then it has the checks described in
CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
checks are not applied. You can disable the trusted gid option by
setting it to 0. This makes all non-root users untrusted.

CONFIG_SECURITY_TPE_STRICT (sysctl=kernel.tpe.strict)

default: n

This option applies another set of restrictions to all non-root users
even if they are trusted. This only allows execution under the
following conditions:

* file is in a directory owned by the user that is not group or
  world-writable
* file is in a directory owned by root and writable only by root

CONFIG_SECURITY_TPE_RESTRICT_ROOT (sysctl=kernel.tpe.restrict_root)

default: n

This option applies all enabled TPE restrictions to root.

CONFIG_SECURITY_TPE_INVERT_GID (sysctl=kernel.tpe.invert_gid)

default: n

This option reverses the trust logic of the gid 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|   5 +
 include/linux/lsm_hooks.h  |   5 +
 security/Kconfig   |   1 +
 security/Makefile  |   2 +
 security/security.c|   1 +
 security/tpe/Kconfig   |  64 
 security/tpe/Makefile  |   3 +
 security/tpe/tpe_lsm.c | 218 +
 9 files changed, 358 insertions(+)
 create mode 100644 Documentation/security/tpe.txt
 create mode 100644 security/tpe/Kconfig
 create mode 100644 security/tpe/Makefile
 create mode 100644 security/tpe/tpe_lsm.c

diff --git a/Documentation/security/tpe.txt b/Documentation/security/tpe.txt
new file mode 100644
index 000..226afcc
--- /dev/null
+++ b/Documentation/security/tpe.txt
@@ -0,0 +1,59 @@
+Trusted Path Execution is a Linux Security Module that generally requires
+programs to be run from a trusted path. A trusted path is one that is owned by
+root and is not group/world writable. This prevents an attacker from executing
+their own malicious binaries from an unprivileged user on the system. This
+feature is enabled with CONFIG_SECURITY_TPE. When enabled, a set of