On Fri, Jan 24, 2014 at 8:01 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
