Re: RSBAC mprotect (was: Kernel 4.4 at m-privacy git)

Am 18.07.2016 um 11:44 schrieb Amon Ott:
> We now have prepatched kernel 4.4 source code at
> https://git.m-privacy.de/linux-mprivacy-4.4.git/
> 
> Unfortunately, the PaX licensing has changed. This means that we cannot
> provide any new prepatched kernels with both RSBAC and PaX. The 4.4
> kernel is already without PaX and 4.1 will not go beyond 4.1.21. Thanks
> to the PaX team for all the good work and good bye...

As partial replacement I have extended RSBAC with a new feature called
"Prevent memory write and execute (mprotect)".

If you enable the new kernel config switch CONFIG_RSBAC_MPROTECT in the
RSBAC menu, RSBAC will per default prevent process memory mappings from
having both EXEC and WRITE access (see man mprotect, man mmap, man
shmat), except for initial library (ELF DYN) mapping relocation.

A new general (GEN) attribute allow_write_exec for PROCESS, FILE, DIR
(for inheritance) allows to change the behaviour. It can be set per
program or per mapped file. "false" means never allow, true always
allow, relocate means initial relocation allowed, inherit is for usual
inheritance from parent DIR.

In my tests, only few programs required the "true" setting, e.g. Firefox
for its JIT compiler for JavaScript. The new debug switch
rsbac_debug_mprotect lets you watch the behaviour in the kernel log,
denied accesses are always logged at info level. All paxtest tests were
successful here.

mprotect can be switched into individual softmode or completely off (and
back on) like decision modules, if enabled in kernel config, just use
MPROTECT as module name.

All the code ist in RSBAC 4.4 kernel git at git.rsbac.org, updated tools
are in rsbac-admin git. The version has been changed to 1.4.10 to
reflect the new functionality, but everything is compatible with older
versions. I have removed the mostly obsolete "DAC disable" feature so
that I could reuse its attribute space in the structures.

I would welcome any feedback, but my answer might be delayed two weeks
because of upcoming holidays.

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