It's sad actually that this is the perfect type of exploit to block with SElinux, a simple write to unauthorized files. But since no one uses the user contexts of selinux then no one blocks this.
Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy.
So this exploit will run unconfined and will be allowed writes everywhere on the system.
I once tried the staff_r role on a Fedora 23 system and it worked out of box but there were more errors and it would not be recommended for beginners.
I believe the same goes for apparmor since apparmor only defines "armor" for processes, not for users. How many use pam_apparmor today? [1]
>Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy.
Just to clarify this, any process you start from the shell. Like the PoC exploit.
But in an actual scenario, if the exploit were launched from Firefox, or Nginx, it would run under a confined context and be prevented from overwriting most critical system files.
> Your shell runs unconfined because your user role is unconfined. Any process you might start will therefore run unconfined, unless stated otherwise in a policy.
I am actually surprised that sane and safe defaults are ignored and left to user's discretion. Most users think Linux is secure by default.
It's interesting to see Windows going into other direction and locking down more and more by default.
Yes, it is ironic that Windows and macOS are the desktop systems taking this route, while GNU/Linux is starting to look like the swiss cheese many FOSS used to joke the other OSes for.
The scale is so high, that kernel security has become a major discussion subject.
Well it's an ongoing effort in Fedora too. Every release of fedora or centos show some improvement around the user of SElinux.
I only wish I had the competence to help out because I think it's a very important effort.
Sad to say that in Fedora 23 I was able to easily put my user into the staff_r role, and thereby confining it. But in fedora 24 there seem to be only three default user contexts defined. Not sure what happened but that likely means I have to define my own user context and then I can't know how well supported it is in the policy.
It's impossible for ordinary users to do any of this.
