search

GrapheneOS / linux-hardened

Minimal supplement to upstream Kernel Self Protection Project changes. Features already provided by SELinux + Yama and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags have stable history. Shared IRC channel with KSPP: irc.freenode.net ##linux-hardened. Currently maintained at https://github.com/anthraxx/linux-hardened.
https://grapheneos.org/
Other
397 stars 105 forks source link

A question about Emutramp #54

Closed Kalle72 closed 7 years ago

Kalle72 commented 7 years ago

At the moment I use hardened Gentoo with a 4.9. grsec kernel. Because this kernel is discontinued, I consider to use your kernel instead.

The "Kernel-Info" about emutamp says: emutramp

This means more or less that without Emutramp not even the package-manager works. Because of this I am wondering why emutramp is an "out of scope feature (legacy)"

PS: Gentoo's site (https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart) says the following about Emutramp:

... do not turn on or off some feature without knowing what you are doing. This is particularly true for EMUTRAMP (Emulate trampolines) which is turned on by default, and turning it off can break python and therefore your system! The reason is that python and libffi write code on the fly, either by RWX mmap-ings which PaX's MPROTECT will kill, or by falling back on trying to write little code snippets to files which other features in Grsecurity will kill, like Trused Path Execution. (See bug #484472.) In Gentoo, we've opted to patch python and libffi to use trampolines that can be safely handled by emulation in a PaX kernel. (See bug #329499.) We then PaX mark the python executable with -E to enable emulation of trampolines. Without EMUTRAMP on in the kernel, python will fail in trying to generate its RWX mmap-ings and die every time. (As a temporary workaround if you get into this situation, you can disable MPROTECT on python with paxctl-ng -m and then restore the original markings once you have booted back into a PaX kernel with EMUTRAMP.)

thestinger commented 7 years ago

I'm aware of what it does and where it's used and it's not going to be implemented in linux-hardened.

GNU nested functions are easy to replace and have become extremely rare since it's a quirky legacy feature. That's the intended purpose of the feature and is why it's marked as legacy.

For Python, http://cffi.readthedocs.io/en/latest/using.html#extern-python-new-style-callbacks no longer depends on libffi like the old-style callbacks and ctypes. Using EMUTRAMP is very inefficient and ends up permitting a form of dynamic code generation / execution. There's dynamic Python bytecode and source code execution either way. It's a full blown general purpose language interpreter with the same capabilities as machine code. Consider what libffi is doing: it's permitting dynamic calls to any native function from Python bytecode / source code.

Access control doesn't really fit into linux-hardened either way but rather belongs in an LSM. I don't plan on carrying any more of those patches. Consider working with the developer of S.A.R.A. http://www.openwall.com/lists/kernel-hardening/2017/09/11/10 if you really want these features in a way that's comparable to how they existed in PaX.

Kalle72 commented 7 years ago

Thanks for your answer. As a consequence, I tested the grsec-kernel with EMUTRAMP deactivated and -- really -- it seems to work well, including the python-based package-manager. (The Kernel-Info seems a relict.) As your patchset provides the other features I used from grsec and I will switch to it.

Thanks for your efforts