[Gc] Allocating Executable Memory
cr88192 at hotmail.com
Mon Jul 26 09:43:02 PDT 2010
----- Original Message -----
From: "Andrew Haley" <aph at redhat.com>
To: "BGB" <cr88192 at hotmail.com>
Cc: <gc at linux.hpl.hp.com>
Sent: Monday, July 26, 2010 9:12 AM
Subject: Re: [Gc] Allocating Executable Memory
> 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
>>>> 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.
in this case: set the policy this certain way or this app is not likely to
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 (SELinux came around long
after I generally switched mostly to Windows development, but most of my
stuff, which tends to include use of RWX memory, seemed to work last I tried
testing some of my stuff on Linux).
on newer Windows at least, anything of this sort usually invokes "UAC" to
make a popup asking whether they should unblock the feature in question, or
continue blocking or terminate the application. usually this is DEP
violations on Win64 apps (DEP is disabled by default for 32-bit user apps),
accessing the network/internet, or trying to make changes to the system.
>> 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.
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.
More information about the Gc