Hello, I just submitted AppArmor 3.0 to Tumbleweed (SR 845533). Since this is a major release, there are also some changes worth mentioning ;-) First and most important: Existing profiles will continue to work - but might cause some warnings on load. However, you'll probably need to take action if you have a program that uses hats, and if you use php-fpm. So, what's new in AppArmor 3.0? * Support for new rule types dbus and unix rules are now enforced. The profiles now also support a xattr conditional. Note that this requires an abi declaration in the profile (next bulletpoint ;-) * abi declarations in the profiles Profiles can (and should) declare for which version of the feature abi they were developed. In most cases, you can simply add abi <abi/3.0>, as the first line of the profile preamble and you are done. This line will enable enforcement of dbus and unix rules - so if your application needs one of these, you'll need to add the needed rules to the profile. Note that enforcement of dbus rules is done in userspace, so AppArmor dbus events will end up in the syslog instead of audit.log. (Hint: use aa-logprof -f /var/log/messages to read from syslog.) If a profile does not have this abi declaration, it will behave as in the 2.x releases and not apply any dbus or unix restrictions. If you package profiles also for older AppArmor versions, the abi rule will cause a warning with 2.x apparmor_parser, but won't break anything. * path-based profile names are deprecated Instead of starting a profile with /bin/foo { it's now recommended to give it a more readable name: profile foo /bin/foo { The name "foo" will be used in the audit.log and also for peer= in some rules, for example signal rules. Named profiles are supported since years and will work on older AppArmor versions without problems. * support for new apparmor proc attr interface In addition to /proc/*/attr/current libapparmor now also supports and uses /proc/*/attr/apparmor/current If you have profiles that allow access to /proc/*/attr/current (for binaries that use hats), you should also allow the new path with the additional "apparmor/" in it. (Make sure you allow the new path in the main profile and all hats.) * new profile for php-fpm AppArmor now ships a profile for php-fpm which is enabled by default. While I hope that this doesn't cause too much trouble, you might need to extend it to match your php-fpm config. https://nordisch.org/posts/php-fpm-apparmor/ should give you some inspiration how you can configure php-fpm to use subprofiles for a pool, and aa-complain / aa-logprof / aa-enforce will make updating the profile easy. As usual - if you have a profile addition that you consider useful for more people, please submit it as a bugreport or patch. * new profile modes kill and unconfined - kill is a sledge hammer-variant of enforce and will kill a process if it violates its AppArmor policy - unconfined is similar to running a process without AppArmor restrictions, with the difference that you can later load a "real" profile to confine the process without restarting it. Note that these flags are still considered experimental. * "under the hood" changes There are also several changes "under the hood", which I'll simply copy from apparmor.changes: - rewritten aa-status (in C), including support for new profile modes - rewritten aa-notify (in python), finally dropping the perl requirement at runtime - new tool aa-features-abi for extracting feature abis from the kernel - update profiles to have profile names and to use 3.0 feature abi - introduce @{etc_ro} and @{etc_rw} profile variables - several updates to profiles and abstractions (including boo#1166007) - fully support 'include if exists' in the aa-* tools - rewrite handling of alias, include, link and variable rules in the aa-* tools - rewrite and simplify log handling in the aa-logprof and aa-genprof * ... and more See https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0 for the detailed upstream changelog - and be aware that I've also applied some post-release fixes to the package before submitting it to Tumbleweed ;-) Regards, Christian Boltz -- "sudo make me a secure IoT device" <world disintegrates with a DIV0 exception> [Stefan G. Lesser on https://plus.google.com/+KristianK%C3%B6hntopp/posts/H7iqYLmomXL] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org