I want to turn on a part of the kernel to make SELinux checking more stringent.

Andrew Lutomirski luto at mit.edu
Fri Jan 24 18:36:58 UTC 2014


On Fri, Jan 24, 2014 at 8:01 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here is the request from upstream to enable this feature in Rawhide, with an
> explanation of what it does.
>
>> "Android is starting to apply execmem and friends to the non-Dalvik
>> components (i.e. non-Java components, primarily the native system
>> daemons). As part of that, I uploaded a change to effectively echo 0 >
>> /sys/fs/selinux/checkreqprot so that we always check the actual protection
>> flags applied by the kernel rather than only checking what the application
>> requested.
>>
>> Originally checkreqprot was to support legacy applications that had no
>> PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we
>> wouldn't have to add execute permission pervasively to policy for such
>> applications.  But it effectively provides a way to bypass policy by
>> creating such an application, and as I later discovered, just by calling
>> personality(READ_IMPLIES_EXEC) from an application at any time. The
>> simplest way to eliminate that bypass comprehensively is to change the
>> defaults for checkreqprot.
>>
>> I think this is likely safe in Fedora since you now allow execmem by
>> default to most domains.  Can we get the same change applied in Fedora,
>> either by changing the default kernel configuration
>> (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in
>> an init script to set the /sys/fs/selinux/checkreqprot value?
>

I admit that I'm extremely late to the party (if I could go back in
time, I'd do my best to nack the relevant kernel parts), but...

Why is execmem part of MAC policy in the first place?  As I understand
it, the point of MAC is to prevent programs (whether malicious,
compromised, or just dumb) from doing things to other parts of the
system that they have no business doing.

execmem restrictions, on the other hand, serves to prevent a program
from doing something *to itself* that may make it easier to compromise
that program.  Note that, by the time you've pwned a daemon hard
enough to get it to call personality, mprotect, or *write another ELF
image with strange flags*[1], you've already gotten past the point
where preventing execmem is going to do any good.

IOW, I consider restrictions to execmem to be in the same category as
-fstack-protector, and I'd be happier if this stuff were split out
from selinux entirely.

(To be fair, if the point is to make it more transparent which
programs are using execmem for legitimate purposes, so that the rest
can be fixed, then something like file labels makes sense.  On the
other hand, sticking an equivalent check into, say, the Fedora RPM
scripts makes even more sense to me.)

[1] Don't even get me started on that one.  If you can get a buggy php
program to write attacker-controlled files, you're not going to write
ELF programs that fiddle with PT_GNU_STACK.  You're going to write ELF
programs that *already contain shellcode*.  So this particular
protection is IMO completely worthless.

--Andy


More information about the devel mailing list