Feature changed by: Stefan Knorr (stfnknorr)
Feature #323500, revision 35
Title: [BETA 5] Kernel: Add support for new AppArmor rule types
openSUSE Distribution: Ready
Requested by: Christian Boltz (cboltz)
Documentation Editor: Sven Seeberg (sven15)
Partner organization: openSUSE.org
[forwarded from https://bugzilla.opensuse.org/show_bug.cgi?id=1042082
Support for several new AppArmor rule types is on the way to the
Also, support for profile stacking will be added and policy namespace
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"
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.
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.
#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
#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
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.
#12: Christian Boltz (cboltz) (2018-04-17 16:53:34) (reply to #11)
Well, more or less - upstreaming was delayed, so not all rule types are
supported in the upstream kernel yet. Support for dbus and unix rules
is still missing. network rules are also not in the upstream kernel
yet, but [open]SUSE carries this patch since years.
Also note that I removed "rlimit" from the release notes sniplet -
rlimit rules are supported since years, so there's nothing new about
OTOH, pivot_root was upstreamed in 4.14, therefore I added it to the
release notes sniplet.
#13: Sven Seeberg (sven15) (2018-04-27 17:47:20)
The shipped man page also includes unix and dbus rules. Is that a
mistake or are these features also included in SLE/Leap 15?
#14: Christian Boltz (cboltz) (2018-04-27 18:24:28) (reply to #13)
Yes and no ;-) unix and dbus rules are supported in userspace
(apparmor_parser, aa-logprof etc.) so that they can handle profiles
that contain these rules. AFAIK dbus userspace also has AppArmor
However, kernel 4.14 doesn't support unix and dbus rules yet, which
means that they get ignored in practise. ("Ignored" means that all unix
and dbus actions are allowed.)
Release Notes: New AppArmor Features to Restrict Processes
- To properly protect processes, they must be safeguarded from not only
- from files and network connections, but also from other process. For
+ To properly protect processes, they must be safeguarded not only from
+ files and network connections, but also from other process. For
example, processes can be arbitrarily terminated by signals from other
The version of AppArmor shipped with SLE 15 includes new features to
further safeguard and restrict your processes. These features include: