[Gc] Allocating Executable Memory

BGB cr88192 at hotmail.com
Mon Jul 26 10:23:10 PDT 2010


----- Original Message ----- 
From: "Andrew Haley" <aph at redhat.com>
To: <gc at linux.hpl.hp.com>
Sent: Monday, July 26, 2010 10:12 AM
Subject: Re: [Gc] Allocating Executable Memory


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

ok.


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

well, presumably the users and sysadmins are one in the same:
said user installs app on their box, and then has to deal with the 
settings...

but, OTOH, many users can't figure out why ODT docs don't open in MS-Offoce, 
or what to do about all these UAC popups... (hell, many possibly think that 
the popup means some hacker is trying to hack their system right there or 
similar...).

even as such, user+app control is still preferable to OS distro-vendor or 
sysadmin control.
the idea of having external sysadmins in control of end-user boxes is 
undesirable, like, unneeded beuracracy...


> Andrew.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list