[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <685A19F8-2CD9-48C2-824E-9C7D593E67F2@belouin.fr>
Date: Sun, 04 Jun 2017 00:02:25 +0200
From: Nicolas Belouin <nicolas@...ouin.fr>
To: kernel-hardening@...ts.openwall.com, Daniel Micay <danielmicay@...il.com>,
Solar Designer <solar@...nwall.com>, Greg KH <greg@...ah.com>
CC: Matt Brown <matt@...tt.com>
Subject: Re: [PATCH v1 1/1] Add Trusted Path Execution as a stackable LSM
Well,
I think it would be interesting to have such option if you don't​ want to go with a full blown SELinux, but want such feature as TPE. The fact that you don't configure it from userspace is good, as you can keep a very minimal system and force an attacker to only use the provided tools to attack the system, without being able to alter nor disable the protection at any time.
On June 3, 2017 7:16:40 PM GMT+02:00, Daniel Micay <danielmicay@...il.com> wrote:
>On Sat, 2017-06-03 at 18:22 +0200, Solar Designer wrote:
>> On Sat, Jun 03, 2017 at 05:59:20PM +0200, Greg KH wrote:
>> > But for those systems, and this feature as well, can't a "simple"
>> > apparmor policy do the exact same thing? Also, I'm sure the
>SELinux
>> > can
>> > do this as well, but I don't know the config language there as
>well.
>> >
>> > So I think this is already a feature that is supported, it just
>> > takes a
>> > bit more configuration work on the admin.
>>
>> Yes, that's "a bit" more effort up to the point where almost(?) no
>one
>> would bother. Sometimes simple features can reasonably co-exist with
>> more general frameworks that could also be used to achieve the
>effect.
>> So I don't view this as a sufficiently good argument against TPE as a
>> feature on its own.
>>
>> Alexander
>
>Some thoughts on this, veering a bit into some loosely related topics:
>
>SELinux can cover the same kind of stuff as PaX MPROTECT (execmem,
>execheap, execstack, execmod) and grsecurity TPE (execute and
>execute_no_trans). Android uses it to enforce comparable rules for most
>of the SELinux domains in the base system, but the Android Runtime JIT
>and Chromium JIT (particularly in the WebView) block the equivalent to
>MPROTECT for much of the app layer and Play Services violates rules
>comparable to TPE in the app layer too. In CopperheadOS, it's taken to
>completion because the WebView sandbox is force enabled and the Android
>Runtime is set to use full ahead-of-time compilation without the JIT.
>Nothing violates the equivalent to the TPE rules in the Android Open
>Source Project. The domain for the Chromium sandbox is the only one
>with
>execmem and only the privileged base system really violates the TPE
>style guarantees (system_server/installd can install an app and run it
>in one of the app domains at the very least).
>
>Beyond these features, there's also a distinction between code from
>verified/trusted partitions (i.e. covered by dm-verity) and from
>partitions that hold persistent state rather than being pristine
>verified OS partitions. There's more to "trust" than just whether only
>root or root / current user can write there. Android *mostly* forbids
>the base system from executing code from outside of those verified
>partitions too, but it falls a bit short and that's something else
>that's finished off in CopperheadOS. I wouldn't go as far as to say it
>makes verified boot work well for anything beyond the usual guarantees
>for factory resets though. There's still a lot of trust in persistent
>state, just not code executed from it by the base system. The SELinux
>label usage also needs to be audited to make sure that an attacker
>can't
>persist unverified SELinux labels that are not replaced. Verified boot
>is really hard to do in a meaningful way. ChromeOS weakened it via
>having an Android userspace in a container since the guarantees dropped
>to those of Android there.
>
>I see why people want lightweight, independent implementations of these
>features but I don't have a use for it anymore. I'm used to having
>great
>full system SELinux policies as a baseline from the Android Open Source
>Project and being able to tweak those existing policies to accomplish
>targeted goals like these. It provides much finer-grained control so it
>can do a lot more and compatibility is easier. The one thing it isn't
>capable of dealing with on Android is a dynamic toggle because Android
>uses a static SELinux policy. It's not possible to have a toggle for
>things like debugging features exposed via toggles over ADB that
>doesn't
>at least require respawning processes to get them into a different
>debug
>domain. That's why perf_event_paranoid=3 is needed for Android even if
>an LSM hook is added there and why ptrace_scope=2 in CopperheadOS does
>something that SELinux (on Android) and seccomp-bpf can't accomplish.
>On
>the other hand, I don't really have any use for TPE since doing it with
>SELinux doesn't interfere with debugging so a toggle isn't needed.
>
>There's always the option of making a stub SELinux policy used for
>little more than covering similar ground to MPROTECT and TPE if that is
>really all someone wants. The policy would be tiny. There can be one
>domain for nearly everything and one for an exception from the rules.
>The labelling would be simple too. I'm curious how minimal that could
>be, but focusing on only those specific micro issues is probably not
>something people are going to do in practice.
Nicolas
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.
