Feature changed by: Libor Pechacek (LPechacek) Feature #323500, revision 27 Title: [BETA 5] Kernel: Add support for new AppArmor rule types openSUSE Distribution: Ready Priority Requester: Important Projectmanager: Important Requested by: Christian Boltz (cboltz) Partner organization: openSUSE.org Description: [forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082 ] Support for several new AppArmor rule types is on the way to the upstream kernel: * dbus * mount * signal * ptrace * pivot_root * unix Also, support for profile stacking will be added and policy namespace support improved. Those new rule types are needed to make Snappy secure - without them, it's hard or even impossible to make sure snaps don't do something they shouldn't. For example, it would be impossible to restrict dbus access to only the required parts. Of course those new rules will also be useful for "normal" applications. Note that adding support for those rules in a service pack is a bad idea because it might need profile updates, therefore it would be a *very* good idea to backport them to whatever kernel will be shipped in Leap 15/SLE 15. The first base patches are already in 4.11. The next bunch is on its way to 4.12, and the goal is to get the final parts into 4.13 and 4.14. Upstream (especially John Johansen) promised to send the pull request for 4.13 in the next days. The remaining patches for 4.14 will follow in about two months - or a bit earlier if you don't insist on the final version of those patches. Addition by John: Unfortunately upstream 4.13 will not be sufficient. The goal now is to get the remaining changes into 4.14. If backporting to an older kernel I would use the git://kernel.ubuntu. com/jj/linux-apparmor-backports tree. A new series of branches will be added based on the 4.13 version of apparmor. It will provide a small patch series (2 base patches - 1 securityfs, 1 apparmor and then any necessary backport patches for the target kernel version). The final version of the 4.13 backport branch will not be available until at earliest the close of the 4.13 merge window. But a early version could be made available next week. Documentation Impact: Security Guide Discussion: #2: Goldwyn Rodrigues (goldwynr) (2017-08-01 19:28:20) I have added the current patches in upstream vanilla tree. Thanks to John's tree, this was simpler than I thought. This series covers namespace labeling and stacking. However, as the first comment (addition) says, the rest would not make it upstream until 4.14. What is remaining is mount, signals, dbus, keys. etc. We do carry some legacy network patches though. I will keep a close watch to see as and when new patches appear. #3: Libor Pechacek (lpechacek) (2017-08-03 09:16:26Z) (reply to #2) Commit e310a9d mentioning this FATE has hit SLE15 tree. #4: Jeff Mahoney (jeff_mahoney) (2017-08-15 14:27:58Z) OpenSUSE will be updated once all of the commits have landed upstream; Likely 4.14. Then we'll update the userspace. #5: Christian Boltz (cboltz) (2017-08-23 18:48:38) (reply to #4) I'd prefer to have the new features also in the openSUSE kernel (especially in Tumbleweed) ASAP so that a) it gets more testing in general and b) I can do more testing which will also help to get the userspace tools in shape. #6: Goldwyn Rodrigues (goldwynr) (2017-09-06 15:56:13) (reply to #5) Tumbleweed should get the patches from upstream v4.13 kernels since Tumbleweed kernel moves pretty fast. I don't think backporting patches is worth the effort. You can also use Kernel of the Day (KOTD) which is already on 4.13-rc2. #7: Libor Pechacek (lpechacek) (2017-09-08 07:12:08Z) (reply to #6) +1 No backports to TW. @Christian, use KOTD with Tumbleweed for your testing. #8: Jeff Mahoney (jeff_mahoney) (2017-09-28 09:40:30) (reply to #7) The kernel master branch is now at 4.14-rc2, which included the net mediation patches finally landing upstream! #9: Mel Gorman (mgorman) (2018-02-23 10:52:52) (reply to #8) Note that this FATE is not without consequences. It pulled in support for mediating signals but the system overhead for signals is massive even if apparmor is not installed and no profiles are loaded. It's visible in any signal microbenchmark. It's also visible in benchmarks like dbench and tbench which are very signal-intensive. This FATE is far from free even when the apparmor package is not installed. #10: Goldwyn Rodrigues (goldwynr) (2018-02-23 13:10:11) (reply to #9) Thanks for testing and letting me know. I assume you are disabling apparmor needs to load in the beginning for security purposes to cover as many programs/profiles as possible. Unfortunately, security has its costs. I believe you disabled apparmor in kernel boot parameters using apparmor=0. I could work on disabling part of the feature as sysfs switch as MgE suggested for RC2 if it is really required. From a practical point of view, I am not sure how many programs are affected by this. I let Jeff or management decide this. + #11: Libor Pechacek (lpechacek) (2018-04-17 06:54:58Z) + Obviously done in SLE 15. Release Notes: Challenge: Processes need to be safeguarded from not just the files or network they are capable to sockets but with other aspects as well. For example genuine processes can be arbitrarily terminated by signals from other processes. Compromised processes can try to exhaust resources by increasing their rlimits. Solution: Apparmor includes new features to further safeguard and restrict your processes. These features include: * mount * rlimit * ptrace * signal -- openSUSE Feature: https://features.opensuse.org/323500