Re: PAX mprotect and JIT

[christos%astron.com@localhost (Christos Zoulas)]

In article <a2ad1ef4-0c31-38b5-9c50-a86f6525543e%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 26.02.2017 15:05, coypu%SDF.ORG@localhost wrote:
>> On Sun, Feb 26, 2017 at 02:52:39PM +0100, Kamil Rytarowski wrote:
>>> Can we have something like MAP_NOMPROTECT?  Something like it would be
>>> used to mmap(2) RWX region:
>>>
>>> void *mapping = mmap(NULL, rounded_size, PROT_READ | PROT_WRITE |
>>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_NOMPROTECT, -1, 0);
>>>
>>> Are doubled mappings more secure than this?
>>>
>> 
>> what pax mprotect does is silently turn RWX mapping to RW.
>> 
>
>What's the [security] difference between fooling and disabling mprotect
>for a memory region?
>
>Is there a room to add this nomprotect allocator in libutil(3) to make
>it convenient to reuse out of libffi?

The point is that you really don't want rwx regions lingering around because
they are easy to exploit. It is one thing allowing going from rw- <-> r-x 
and another leaving things open all the time.

The problem we are trying to solve here is that we don't allow those transitions
at all forcing programs that need to do them (JIT like java and function
trampoline providers like libffi) to:

1. Mark the binary via paxctl (which works for java because and friends because
   there are few such binaries)
2. Run through hoops (creating a file on disk with the executable code in order
   to map it (like libffi) because you can't possibly know who's linked against
   libffi in order to mark it as in (1).

Any type of foreign API we introduce (MREMAP_DUP or whatever) we'll have to
maintain separate patches for (which is not that bad), instead of teaching
libffi (and friends) that we are like SE/Linux and we need to write
files for PaX (which is disgusting). Perhaps it is simpler to just allow
these transitions (rw- <-> r-x) by using an madvise(2) call.

The other choice that we made following the original PaX was not to refuse
the request to change the mappings, but silently enforcing them which is
questionable. There were patches in the lists to change this behavior but
nobody commented about them.

christos