RFR: Disable PaX mprotect on executables
david.holmes at oracle.com
Thu Apr 13 08:06:35 UTC 2017
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  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.
> 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.
>>> 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.
>>>  http://pax.grsecurity.net
More information about the portola-dev