[Gc] Allocating Executable Memory

Andrew Haley aph at redhat.com
Mon Jul 26 10:12:00 PDT 2010

On 07/26/2010 05:43 PM, BGB wrote:
> ----- Original Message ----- From: "Andrew Haley" <aph at redhat.com>
>> On 07/26/2010 04:31 PM, BGB wrote:
>>> ----- Original Message ----- From: "Andrew Haley" <aph at redhat.com>
>>>> On 07/26/2010 03:37 PM, BGB wrote:
>>>>> ----- Original Message ----- From: "Andrew Haley" <aph at redhat.com>
>>>>>> On 07/24/2010 11:04 AM, Ivan Maidanski wrote:
>>>>>>> Sat, 24 Jul 2010 09:50:38 +0100 Andrew Haley <aph at redhat.com>:
>>>>>>>> Some distributions forbid the allocation of memory that is
>>>>>>>> mapped writable and executable, and I think the number of such
>>>>>>>> distributions will increase over time.  On such systems Java is
>>>>>>>> marked with a special file attribute, and that attribute is
>>>>>>>> writeable only by root.
>>>>> admittedly, I don't really know why distros would make this
>>>>> restriction,
>>>>> as personally it seems restrictive and ill-concieved (and liable to
>>>>> break many otherwise functional apps).
>>>> Surprisingly, it breaks very few apps, because very few apps ever need
>>>> to do this sort of thing.  However, it prevents the use of one of the
>>>> most common techniques used by security exploits.
>>> this should still be a matter of app policy, rather than OS policy.
>> Well, I don't know about that.  The owner of the computer can set the
>> policy however they want.
> fair enough.
> in this case: set the policy this certain way or this app is not likely
> to work...
> if this is via SELinux or similar, 


> I haven't really looked into it enough to know what happens when an
> app violates said policy

The system call fails with an EINVAL: whatever happens next is up to
the app.

>>> if the app doesn't need RWX memory, it should not allocate it, and if it
>>> does, then this is the apps' problem.
>>> and, then, if the app does actually request RWX access, then the OS
>>> should give it such.
>> I don't really understand this argument.  Systems used to work this
>> way, and this resulted in security exploits.  Now, system
>> administrators can enable this permission or not on a file-by-file
>> basis, as they see fit.  They can even enable it over the whole OS.
> granted, ok.
> however, the issue here is if the "administrator" knows enough about
> what is going on to understand these settings (like, what they mean, or
> how to change them). the UAC system is annoying, as it often pops up a
> bit many such pop-ups, and tends not to remember prior answers in many
> cases (typically with Control Panel, which is where maybe 75% of UAC
> annoyance comes from). (a nice feature would be a "don't ask me this
> again" checkbox, like in many other apps...).
> very often, users end up disabling UAC altogether and generally
> switching to a less secure mode of operation, mostly so that they can go
> along without being bothered by these popups and having apps work
> without issue.

Sure.  To get back to the issue at hand, in the long term it makes
sense for apps that don't really need RWX memory not to use it: a JIT
doesn't really need RWX memory.  There is a problem with legacy JITs
that can't be rewritten, but writers of new ones need to be aware of
problems they will encounter.

I don't think that any writer of a JIT today really wants to have to
deal with users who don't understand why they have to beg their
sysadmins to disable some security flags.  If it's at a university,
the response of said sysadmin may be short and to the point.

In other words: don't shoot the messenger.  :-)


More information about the Gc mailing list