[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170603154707.GA19161@openwall.com>
Date: Sat, 3 Jun 2017 17:47:07 +0200
From: Solar Designer <solar@...nwall.com>
To: Matt Brown <matt@...tt.com>
Cc: kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
Matt,
On Sat, Jun 03, 2017 at 01:53:51AM -0400, Matt Brown wrote:
> This patch was modified from Brad Spengler's Trusted Path Execution (TPE)
> feature in Grsecurity and also incorporates logging ideas from
> cormander's tpe-lkm.
>
> Modifications from the Grsecurity implementation of TPE were made to
> turn it into a stackable LSM using the existing LSM hook bprm_set_creds.
> Also, denial messages were improved by including the full path of the
> disallowed program. (This idea was taken from cormander's tpe-lkm)
>
> Trusted Path Execution is not a new idea:
>
> http://phrack.org/issues/52/6.html#article
FWIW, I think this is mostly a misfeature, which I deliberately didn't
merge into -ow patches back then.
> 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: root is never restricted by TPE
> 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
>
> * Issues:
> * Can be bypassed by interpreted languages such as python. You can run
> malicious code by doing: python -c 'evil code'
Yes, and not only that: a local attacker may also bypass TPE by what
would have been non-security bugs in many other programs - e.g., a
buffer overflow by a command-line argument in any of the allowed
programs suddenly becomes security-relevant.
A variation of your threat model 1, which makes more sense to me than
what's traditionally implied, is when the attacker does not yet use an
interactive shell. TPE can in fact frustrate automated remote exploits
that don't specifically target (nor support) TPE-enabled systems.
> 2. Attacker on system replaces binary used by a privileged user with a
> malicious one
>
> * This situation arises when administrator of a system leaves a binary
> as world writable.
>
> * TPE is very effective against this threat model
This makes more sense to me. It's known-bypassable policy enforcement
by the sysadmin against one's own human error and such. However, for
this to be effective the exception "NOTE: root is never restricted by
TPE" should be removed or made an option.
In a similar spirit, it'd also make sense to have a policy disallowing
at least root to write into directories writable by other users without
setting the O_EXCL flag. I actually had this in a kernel module, which
I used to find issues of this kind in Postfix in 2006 or so (Wietse
promptly patched those), but I didn't try running this in production.
Summary: I see little value in TPE, but I don't intend to argue against
it any further (and I deliberately dropped the CC list on this reply,
not to hamper your efforts much). If you choose to proceed with trying
to upstream it anyway, I suggest the above changes to the description of
the threat models and the tiny code change to allow for restricting root
as well.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
