[rsbac] RSBAC mprotect

[Amon Ott]

Am 05.08.2016 um 19:42 schrieb Javier Juan Martínez Cabezón:
> Amon, PaX is a derivative work of a standard linux kernel isn't it, it
> should maintain the GPL license or not? For example could you close the
> rsbac kernel source code?

This is my idea of GPL, too, but it is their decision. I am convinced
that closing RSBAC code would violate GPL and could lead to severe legal
problems, but even if it was allowed, I would not.

> Have you talked with pipacs and spender? maybe they could relicense to
> you PaX source code to use with rsbac.

I have in the name of m-privacy and they did not like the idea of us
publishing a pre-patched kernel with both RSBAC and PaX. So I started
working on an alternative that closes the most important issues for us.

> Damn I like this new feature, may be could be time to call rsbac 1.5
> when being stable, may be could co-exist hooks to standard pax with the
> standard PaX module and one module MPROTECT if you decide to implement
> your own PaX version.

1.5 would be fine for me. AFAIK, RSBAC still co-exists fine with PaX, if
you have a valid PaX license and merge the patches successfully.
However, I am not going to do these merges any longer. Some day the
RSBAC PAX module might disappear, because I cannot test it any more.

> Do you have plans to extend MPROTECT module to implement for example
> PageExec (may be using SCD NONE EXECUTE), UDEREF etc etc etc?

PageExec is much more complicated than mprotect, so I have no plans to
reimplement that. RSBAC mprotect uses the standard kernel flags for
memory mappings.

Standard kernel already does randomization for programs and libs, only
with fewer Bits than PaX.

We catch mapping calls with mmap(), mprotect() and shmat(), so
everything a process does explicitely to access memory with both write
and execute. After that, we have to rely on standard kernel code to
really protect the pages. AFAIK, it does use NX bit when available.

If READ implies EXEC on some system, we cannot catch all cases, because
READ and WRITE together must be allowed. In my understanding, on X86
systems this should only happen under 64 Bit kernel with some 32 Bit
programs. However, memory code is complicated and I may have missed
something. Please correct me, if you know more than I do.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22