[Gc] Allocating Executable Memory

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


On 07/26/2010 04:31 PM, BGB wrote:
> 
> ----- Original Message ----- From: "Andrew Haley" <aph at redhat.com>
> To: <gc at linux.hpl.hp.com>
> Sent: Monday, July 26, 2010 7:55 AM
> Subject: Re: [Gc] Allocating Executable Memory
> 
> 
>> On 07/26/2010 03:37 PM, BGB wrote:
>>>
>>> ----- Original Message ----- From: "Andrew Haley" <aph at redhat.com>
>>> To: <gc at linux.hpl.hp.com>
>>> Sent: Monday, July 26, 2010 6:29 AM
>>> Subject: Re: [Gc] Allocating Executable Memory
>>>
>>>
>>>> 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.

> 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 undersatnd this argument.  Systms 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.

Andrew.


More information about the Gc mailing list