Uh, why?

To provide the ptrace_scope restriction, as described in linux/Documentation/security/Yama.txt.

To be precise, this would involve adding:
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_YAMA_STACKED=y

The latter enables it to stack with SELinux (or any other primary security module).

So here are some more questions.

- How does Yama interact with SELinux?  I get that it requires the YAMA_STACKED option, but is there any policy interaction or userspace changes that need to go with this?

- Didn't we do something very similar to the ptrace_scope stuff in SELinux itself?  We used to carry selinux-apply-different-permission-to-ptrace-child.patch in our kernel and it sounds very similar.  Why was that abandoned and why is this better?

- Why do we want to enable something path based (noticed by the select SECURITY_PATH)?  I thought path based security was... iffy.

- What are the performance hits of this?

- Why now?  This has been in the kernel in a stackable manner since Sep 2012.

1) they should not interact.  we may need new selinux labels on the yama sysctl knobs and allow these where needed.  Paul, sds,  did either of you run into any problems?  These would be selinux policy fixes needed, not kernel.

2) selinux, being mandatory, rather than discretionary, meant that we had trouble creating a policy which was flexible enough to allow ptrace where needed but still useful.  We failed.  Since with yama programs get to themselves decide who is allowed to ptrace and who isn't, it means stuff works without having to do it all in the admin defined policy.

3) we don't actually need the pathname based stuff.  yama used to have checks around following symlinks in sticky bit directories.  those moved into the core VFS, but the requirement to build the PATH hooks were never removed.  this should be patched out.

4) they should be nearly non-existent.  GDB might be a couple of cycles slower, but not going to measurable

5) well, i did ask for it back in 2012, but got distracted and wandered away.  Upstream is working on a more flexible configurable stacking mechanism and so it was noticed that fedora didn't have this security hardening option enabled.

(In reply to Eric Paris from comment #5)
> 1) they should not interact.  we may need new selinux labels on the yama
> sysctl knobs and allow these where needed.  Paul, sds,  did either of you
> run into any problems?  These would be selinux policy fixes needed, not
> kernel.

SELINUX+YAMA+YAMA_STACKED passed the selinux-testsuite fine.  No need for userspace configuration of Yama unless you want something other than the default (1 - restricted ptrace, change to 0 for original ptrace permissions, 2 for admin-only use of ptrace, 3 - no use of ptrace at all), in which case you just write to /proc/sys/kernel/yama/ptrace_scope.  /proc/sys/kernel/yama/ptrace_scope should just be labeled the same as other /proc/sys/kernel nodes by default, i.e. sysctl_kernel_t, so anything that can set other /proc/sys/kernel knobs can change this.

Ok, I'll look at this Monday.  Bonus points if you get the select SECURITY_PATH dropped upstream by then.

Thanks for the replies and the patch.  You get 1e1000 bonus points.

I've added the patch and enabled YAMA as noted for the f22 and rawhide branches.  It will be present in the 4.0-rc2 build, whenever those are done.  I'm hoping if issues arise that I can ping you all for help.

kernel-4.0.0-0.rc2.git0.1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/kernel-4.0.0-0.rc2.git0.1.fc22

Package kernel-4.0.0-0.rc2.git0.1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-4.0.0-0.rc2.git0.1.fc22'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-3060/kernel-4.0.0-0.rc2.git0.1.fc22
then log in and leave karma (feedback).

Thanks Josh.  If there are any problems don't hesitate to ping me and I'll run them down.

kernel-4.0.0-0.rc3.git0.1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/kernel-4.0.0-0.rc3.git0.1.fc22

kernel-4.0.0-0.rc3.git0.1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

This appears to be the cause of bug 1209492.

Please ensure this change - if kept - is widely announced.

Can I just add a +1 to Frank’s comment!  I just wasted quite a lot of time with SELinux trying to figure out why ptrace was not working any more, and there doesn’t seem to be any documentation for this change (that comes up in a reasonable Google search at least).  That the official Fedora documentation only mentions SELinux for ptrace control effectively mentally “masks” the Yama hits that refer mostly to Ubuntu etc.