Hi,
Following a conversation I had with John a few months ago at the LSS-NA.
Here is a (non-exhaustive) list of things that are useful when working
on large profiles set [0]. For more context, you can find my talk to
LSS-NA [1] and the slide [2]. I know they may have been work already in
these area, this email mostly aim to put the accent on the feature that
are the most needed (in my opinion).
**Current/Planned Rules**
- The ability to transition to another profile in pivot_root is needed
for most sandbox manager profiles. This would allow a profile to
transparently transition to a sandboxed profile without the help of the
sandboxing program (Eg: flatpak, steam, toolbox...)
- The reg ex exclusion has proposed in the doc [3] ({*^}, {**^}) would
be quite useful too.
- The globbing syntax having (where [0-9]* means a digit, followed by
any number of any character) is confusing for everyone. Furthermore, the
way the profiles are usually written I am pretty sure this would not
break too many profiles to update this to a more common syntax
Updating the doc to clearly show what is already implemented and what is
planned would be nice too.
**Conditional Statement**
A lot of resource access depends on some global settings/software
installed on the system. Eg: the desktop environment, X11, Wayland, the
package manager... Therefore, having some sort of conditional statement
in the profile could make sense. That can mostly be sugar syntax,
however, some conditions may need to be checked on execution, while for
other, simple directives (like: `only: apt`) parsed during package build
could work.
**no-new-privs**
To the surprise of no one, this is a pain... While most profiles do not
need it at all, some very important profiles are really dependent on it.
For example, it is currently not possible to properly confine systemd
and therefore, to have full system confinement without it.
**Snap**
Some snap based profile (dynamically generated by snap itself) breaks
when using with apparmor.d [0]
An example with the Ubuntu Store that does not start and raise the
following audit log:
```
DENIED snap.snap-store.ubuntu-software dbus_method_call
org.freedesktop.DBus send bus=session path=/org/freedesktop/DBus
interface=org.freedesktop.DBus member=RequestName peer_label=dbus-daemon
```
The snap.snap-store.ubuntu-software profile is expecting an unconfined
peer_label, not the dbus-daemon profile.
**Profiles really long to load**
Using apparmor.d with Gnome raises a curious issue: the system needs
over a minute to load, without raising any gnome or apparmor related
logs. However, it is as fast as expected without apparmor.d or when
Gnome is not present (on server for example).
I am attaching the systemd logs for more details: without apparmor [4]
and, with apparmor [5] enabled. They have been generated on an Archlinux
based VM made with [6]. The VM can be generated as detailed in [7].
That is all for now. I am going to test the alpha version of apparmor 4
with the new network rules it looks promising...
[0]: https://github.com/roddhjav/apparmor.d
[1] https://www.youtube.com/watch?v=OzyalrOzxE8
[2]
https://lssna2023.sched.com/event/1K7bI/building-the-largest-working-set-of-apparmor-profiles-alexandre-pujol-the-collaboratory-tudublin
[3]:
https://gitlab.com/apparmor/apparmor/-/wikis/AppArmor_Core_Policy_Reference#apparmor-globbing-syntax
[4]:
https://privatebin.net/?318a3f5d601c0d83#H1SCAquJp4tcaezDhnSjKeMGk66zLRdUx8k7jLKq75tE
[5]:
https://privatebin.net/?cdaac3f1051aad22#CbGrksjKJwrjEAFo7rzgWCV57SgW4jRjg9B99sT44UTy
[6]:
https://github.com/roddhjav/apparmor.d/blob/main/tests/packer/init/archlinux-gnome.user-data.yml
[7]:
https://apparmor.pujol.io/development/integration/#test-virtual-machines
Regards,
Alex
