Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
As was pointed out to me, the first grsecurity's implementation of TPE date back to earlier days (before Git was used for Linux): https://github.com/linux-scraping/grsecurity-patches/blob/master/grsec-2.4.5/grsecurity-1.4-LIDS-2.4.5.patch There seem to be multiple implementations inspired by the Phrack articles. This may be worth to take a look at this different approaches. Mickaël On 04/06/2017 18:43, Mickaël Salaün wrote: > Hi, > > If you want to get some information about the history of TPE in > grsecurity, take a look at > https://github.com/linux-scraping/linux-grsecurity/ and run git log > grsecurity/grsec_tpe.c > > Here are some links about TPE (before grsecurity used it): > * http://phrack.org/issues/52/6.html#article > * http://phrack.org/issues/53/8.html#article > * https://lwn.net/Articles/32087/ > * > https://www.usenix.org/legacy/event/usenix04/tech/freenix/full_papers/rahimi/rahimi_html/ > > You may want to adjust the credits. > > A more flexible way to configure TPE options (sysctl) may be considered too. > > Regards, > Mickaël > > On 03/06/2017 07:53, 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 >> >> | A trusted path is one that is inside is 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. >> >> This Trusted Path Execution implementation introduces the following >> Kconfig options and sysctls. These config behaviors are taken straight >> from Grsecurity's implementation. >> >> CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled) >> >> 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 >> >> CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid) >> >> This option defines a group id that, by default, is the untrusted group. >> If a user is untrusted then it has the checks described in >> CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the >> checks are not applied. Since root is never restricted by TPE, you can >> effectively remove the concept of a trusted or untrusted group by >> setting this value to 0. >> >> CONFIG_SECURITY_TPE_ALL (sysctl=kernel.tpe.restrict_all) >> >> This option applies another set of restrictions to all non-root users >> even if they are trusted. This only allows execution under the >> following conditions: >> >> * file is in a directory owned by the user that is not group or >> world-writable >> * file is in a directory owned by root and writable only by root >> >> CONFIG_SECURITY_TPE_INVERT (sysctl=kernel.tpe.gid_invert) >> >> This option reverses the trust logic of the gid option and makes >> kernel.tpe.gid into the trusted group. This means that all other groups >> become untrusted. This sysctl is helpful when you want TPE restrictions >> to apply to most of the users on the system. >> >> 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' >> >> 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 >> >> Signed-off-by: Matt Brown >> --- >> MAINTAINERS | 5 ++ >> include/linux/lsm_hooks.h | 5 ++ >> security/Kconfig | 1 + >> security/Makefile | 2 + >> security/security.c | 1 + >> security/tpe/Kconfig | 57 +++ >> security/tpe/Makefile | 3 + >> security/tpe/tpe_lsm.c| 175 >> ++ >> 8 files changed, 249 insertions(+) >> create mode 100644 security/tpe/Kconfig >> create mode 100644 security/tpe/Makefile >> create mode 100644 security/tpe/tpe_lsm.c >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 38d3e4e..1952bd6 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -11357,6 +11357,11 @@ T: git >> git://git.kernel.org/pub/scm/li
Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
Hi,
If you want to get some information about the history of TPE in
grsecurity, take a look at
https://github.com/linux-scraping/linux-grsecurity/ and run git log
grsecurity/grsec_tpe.c
Here are some links about TPE (before grsecurity used it):
* http://phrack.org/issues/52/6.html#article
* http://phrack.org/issues/53/8.html#article
* https://lwn.net/Articles/32087/
*
https://www.usenix.org/legacy/event/usenix04/tech/freenix/full_papers/rahimi/rahimi_html/
You may want to adjust the credits.
A more flexible way to configure TPE options (sysctl) may be considered too.
Regards,
Mickaël
On 03/06/2017 07:53, 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
>
> | A trusted path is one that is inside is 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.
>
> This Trusted Path Execution implementation introduces the following
> Kconfig options and sysctls. These config behaviors are taken straight
> from Grsecurity's implementation.
>
> CONFIG_SECURITY_TPE (sysctl=kernel.tpe.enabled)
>
> 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
>
> CONFIG_SECURITY_TPE_GID (sysctl=kernel.tpe.gid)
>
> This option defines a group id that, by default, is the untrusted group.
> If a user is untrusted then it has the checks described in
> CONFIG_SECURITY_TPE applied. Otherwise, the user is trusted and the
> checks are not applied. Since root is never restricted by TPE, you can
> effectively remove the concept of a trusted or untrusted group by
> setting this value to 0.
>
> CONFIG_SECURITY_TPE_ALL (sysctl=kernel.tpe.restrict_all)
>
> This option applies another set of restrictions to all non-root users
> even if they are trusted. This only allows execution under the
> following conditions:
>
> * file is in a directory owned by the user that is not group or
> world-writable
> * file is in a directory owned by root and writable only by root
>
> CONFIG_SECURITY_TPE_INVERT (sysctl=kernel.tpe.gid_invert)
>
> This option reverses the trust logic of the gid option and makes
> kernel.tpe.gid into the trusted group. This means that all other groups
> become untrusted. This sysctl is helpful when you want TPE restrictions
> to apply to most of the users on the system.
>
> 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'
>
> 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
>
> Signed-off-by: Matt Brown
> ---
> MAINTAINERS | 5 ++
> include/linux/lsm_hooks.h | 5 ++
> security/Kconfig | 1 +
> security/Makefile | 2 +
> security/security.c | 1 +
> security/tpe/Kconfig | 57 +++
> security/tpe/Makefile | 3 +
> security/tpe/tpe_lsm.c| 175
> ++
> 8 files changed, 249 insertions(+)
> create mode 100644 security/tpe/Kconfig
> create mode 100644 security/tpe/Makefile
> create mode 100644 security/tpe/tpe_lsm.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 38d3e4e..1952bd6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11357,6 +11357,11 @@ T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git yama/tip
> S: Supported
> F: security/yama/
>
> +TPE SECURITY MODULE
> +M: Matt Brown
> +S: Supported
> +F: security/tpe/
> +
> SENSABLE PHANTOM
> M: Jiri Slaby
> S: Maintained
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index e29d4c6..d017f49 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1920,5 +1920,10 @@ void __init loadpin_add_hooks(void);
> #else
> static inline void loadpin_add_hooks(void) { };
> #endif
> +#ifdef CONFIG_S
Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
On 06/03/2017 06:39 AM, Jann Horn wrote: On Sat, Jun 3, 2017 at 7:53 AM, 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) [...] Threat Models: [...] 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 How do you end up with world-writable binaries in $PATH? Sys Admin screw up. It also protects against world-writable binaries anywhere on the system, not just in $PATH.
Re: [kernel-hardening] [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
On Sat, Jun 3, 2017 at 7:53 AM, 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) [...] > Threat Models: [...] > 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 How do you end up with world-writable binaries in $PATH?
