RFR: Disable PaX mprotect on executables

[David Holmes]

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!).

> 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.

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
>>>
>