[info] Attempt to upstream TPE

[ghost]

There is attempt to get TPE into mainline http://openwall.com/lists/kernel-hardening/2017/06/03/11 partially based on your work. It would be nice if you can add your feedback/review (I'm not the submitter).

[cormander]

Thanks for the heads up. I haven't done any work with openwall or directly with the mainline kernel before - so pardon my ignorance here. How do I add to the discussion? That patch is quite horribly incomplete. Mainly, it's missing the mmap and mprotect attack vectors for full TPE enforcement.

[ghost]

I think you can subscribe your email here at bottom of page http://www.openwall.com/lists/kernel-hardening then reply in the chosen topic.

Also I think mmap and mprotect are out of scope of this patch. It's only for TPE as it was in original grsec patch (Trusted Path Execution is a security feature that denies users from executing programs that are not owned by root, or are writable).

Mprotect and mmap belonged to PAX part of grsecurity. Your version is much more advanced as it combines TPE,mprotect, proc hardening, etc. but I think mprotect isn't suitable for mainline as it breaks too much userspace.

If this patch got merged you could keep your module but focus only on other parts beyond pure TPE.

[cormander]

mmap and mprotect aren't out of scope of TPE, you can bypass normal execution on the command line with ld-linux.so. See this script in my test suite:

https://github.com/cormander/tpe-lkm/blob/master/tests/ld-linux-trick.sh

I also spotted the "Stop the plagiarism" thread on that mailing list, related to this. This is concerning.

[ghost]

To my knowledge ld-linux bypass of noexec was fixed long time ago. (your script didn't work for me)

Yes, the attribution part of those patch should be much improved with credits to grsecurity and you, I believe it's wasn't intentional. I don't know if you follow grsecurity guys but they are known to be angry at any attempt to upstream their work. You can judge yourself by looking at other patches (beyond this TPE thing) if they got enough attribution (how many times their work is mentioned there).

[cormander]

The bypass was solved in the "noexec" mount flag yes, and is default in tmpfs and such, but from a kernel module standpoint you still need to hook security_mmap_file and security_file_mprotect. I'm running a 4.11 kernel and if I comment out the hooking of either of those, I get test failures. The same applies to an in-tree module.

I've subscribed to the list. I may reply at some point.

[ghost]

Ok. You can also point your concerns here https://github.com/thestinger/linux-hardened/issues/33 (it's a volunteer's project trying to mainline most grsecurity features.

[nmatt0]

I'm mobile atm but I just wanted to comment here quickly on a couple of things.

1. I did not mean to fail in giving proper credit to you or grsecurity. That will be fixed in v2 of my patch.
2. I really want any feedback/improvements that you have to offer.

[cormander]

Ping me when v2 is ready. Thanks.

[nmatt0]

This is my current work towards a v2: https://github.com/nmatt0/linux-hardened/commit/c76b0dba28cfc0b403353b003c6fff9a22c9ba31

All I've done so far is add in the copyright notice that Grsecurity wants. I didn't copy any code from your project, rather was just inspired by some of the details that you were logging in error messages. I did try to acknowledge this in the commit message. I'm happy to receive any input that you have for improvements. I'm still waiting to figure out the possible race condition that was brought up: http://www.openwall.com/lists/kernel-hardening/2017/06/03/12

Also any additions to the threat model justification in the commit message would be great.

I realize that tpe-lkm had some additional protections (mmap,mprotect) that the Grsecurity TPE did not. I think these could be separate LSMs, but could be persuaded otherwise.

[cormander]

Grsecurity certainly had a lot of code in their mmap and mprotect hooks, but a portion of it did involve TPE. Have a look at these parts of my test suite to see what I mean:

https://github.com/cormander/tpe-lkm/blob/master/tests/ld-linux-trick.sh https://github.com/cormander/tpe-lkm/blob/master/tests/perl-mmap-test.sh

An exec call to the ld-linux.so will mmap the argument given and execute it. I don't know how to guard against that without hooking mmap. There's also the vector of running perl (or some other interpreter) against a script, which TPE won't stop, and have that call a .so file you've crafted to execute system level code instructions. Both mmap and mprotect play a role here.

Regarding the race condition - I'm unsure, sorry.

[nmatt0]

I'm new to a lot of this but I see you're point. Grsecurity definitely did the mprotect stuff outside of TPE by marking executable (either with xattrs or elk headers). There has been talk in ##linux-hardened on freenode about trying to extract and upstream mprotect from PaX. If we did that then we wouldn't need mprotect in TPE. However I do see value in putting mprotect and mmap features in TPE and what do you know, there are already LSM hooks!

https://github.com/torvalds/linux/blob/master/include/linux/lsm_hooks.h#L472-L485

[nmatt0]

Also if you want to work together on this and submit PRs, this is my working TPE repo: https://github.com/nmatt0/linux-hardened/tree/nmatt-dev2

[nmatt0]

@cormander I've got what I think will be my v2 ready to go. https://github.com/nmatt0/linux-hardened/commit/fff829550fbb3ee0b491408a78783ca564d3f16e

Please let me know if you find my attribution of your work and the copyright message acceptable.

I pulled mprotect and mmap functionality from your project and implemented it with the existing LSM hooks. Also, I added a sysctl "tpe.restrict_root" that is the same as your "paranoid" option.

will have edits for coding style/checkpatch fixes before I submit.