RFR: Disable PaX mprotect on executables

[Mikael Vidstedt]

> On Apr 13, 2017, at 1:06 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 13/04/2017 5:31 PM, Erik Joelsson wrote:
>> On 2017-04-13 07:00, David Holmes wrote:
>>> Hi Mikael,
>>> 
>>> On 13/04/2017 9:09 AM, Mikael Vidstedt wrote:
>>>> 
>>>> Alpine by default has PaX [1] enabled. Among other things, PaX tries
>>>> to prevent various attack vectors by controlling the ways in which
>>>> page protection can be updated/changed. For example, it does not
>>>> allow marking previously writable pages as executable. Guess what
>>>> hotspot likes to do?
>>>> 
>>>> This change is incomplete, and I could use some help figuring out how
>>>> to complete it.
>>> 
>>> In all seriousness I would not do this. I think it is up to the
>>> "deployer" of a JRE on such a system to take whatever PaX related
>>> steps are needed to allow the binaries to run. I don't think we should
>>> be making any such decisions at build time, nor requiring paxctl be
>>> available. All we should do is document what is required.
>>> 
>> I think we do have to support this. Alpine is the platform we are being
>> asked to support and our bits will be DoA unless this is done. This will
> 
> I look at this from the perspective of a security conscious user. If I have chosen a hardened platform, and I am choosing software I want to run on that platform, then I want to decide how/whether security should be relaxed for a given binary - not some third-party (and especially not the third-party that supplied the software that I don't necessarily trust!).

That is definitely a very good point - I’ll have to digest.

One of the things we may want to do in either case is add an explicit test during boot to check if a mmap/mprotect call (mimicking the normal operation we do) fails, and if we notice that the test fails we can perhaps recommend the user to look into the PaX settings, and refer to paxctl. 

> 
>> get very annoying quickly when trying to test the bits. Unless, of
>> course, we only support and test on alpine in containers. Whichever we
>> do, it needs to be documented.
> 
> For our own testing I suggest running Alpine with PaX disabled.

It is indeed possible to disable PaX globally on the system using some sysctl voodoo (which is how I got started).

Cheers,
Mikael

> 
> David
> -----
> 
>> You are correct that this has nothing to do with muscl, so I think it
>> should be controlled with a specific configure flag (--enable-pax?) and
>> it should be default off. We would need to put paxctl in the devkit for
>> the affected platform(s) since it's not default installed on our build
>> platforms today (or create a separate package with it, perhaps easier).
>> In our jib profile configuration we would enable this for the alpine
>> linux builds.
>> 
>> Supporting running the build on a PaX enabled system is a different
>> issue. If we want to support this, then we could have configure detect
>> that PaX is currently active (I assume that's possible) and take the
>> necessary precautions to use paxctl on at least the buildjdk, and if not
>> cross compiling, also the target jdk. This would be the only case where
>> the default value of the flag would be true.
>> 
>> /Erik
>> 
>>> David
>>> -----
>>> 
>>>> http://cr.openjdk.java.net/~mikael/webrevs/portola/paxctl/webrev.00/webrev/
>>>> 
>>>> 
>>>> Basically, it all comes down to needing to use a tool - paxctl - to
>>>> mark the executables in a way so that the kernel knows to
>>>> disable/relax some of the PaX features for the process. The patch
>>>> adds support for finding the paxctl tool, and for using the tool (if
>>>> found) to mark the excutable. However, here are two of the main
>>>> reasons why this patch is incomplete:
>>>> 
>>>> * There are two different JDKs which may or may not need the special
>>>> paxctl treatment: buildjdk and target jdk. When building the JDK on
>>>> Alpine (really: on a PaX enabled system) the buildjdk needs to have
>>>> its executables marked as well, but when cross compiling that’s not
>>>> necessarily needed.
>>>> * The patch currently bases the decision on whether to mark the
>>>> executables on whether the target CLIB is “musl”, where in fact that
>>>> doesn’t really have anything to do with musl
>>>> * Not all executables necessarily load and run the JVM, so not all of
>>>> them necessarily need to be marked
>>>> * It’s not really the user space that decides whether the PaX
>>>> relaxation is needed - it’s the kernel. That means that when running
>>>> in, say, Docker, even if the base image would be Alpine (or some
>>>> other distribution which has PaX enabled by default), it’s really the
>>>> configuration of the host system kernel which comes into play.
>>>> 
>>>> I’m not sure what the right solution is here. Taking suggestions.
>>>> 
>>>> Cheers,
>>>> Mikael
>>>> 
>>>> [1] http://pax.grsecurity.net