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 ,
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