On 7/17/23 16:28, Alexandre Pujol wrote:
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).
Hey Alexandre, thanks for writing this up
**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...)
yes this has been experimented with, though I don't know if we will ever get it
upstream. We might be able to get a limited form if, we can should there is a
single task within the namespace. The problem comes down to pivot_root applies
to all tasks within the namespace and walking a switch all tasks (generic case)
isn't going to get upstream.
I have been playing with a more limited update a shared variable model, that
would allow for a change without having to walk all tasks in an ns within a
pivot_root hook.
- The reg ex exclusion has proposed in the doc [3] ({*^}, {**^}) would be quite
useful too.
well globbing ...
- 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
this can't change, it would break policy, even if we update all policy in the
system there is policy being shipping by too many other projects. For better or
worse the apparmor rules are based on shell globbing not RE or eRE. There is a
potential for exposing a full RE with special syntax. Something like
^/foo[1-7]*$
so basically using RE anchoring to indicate the rule is using RE instead of
globbing. This of course is just one potential way of expressing this.
Suggestions are welcome
Updating the doc to clearly show what is already implemented and what is
planned would be nice too.
yeah the docs need serious work
**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.
yep. This is a WIP, I don't know if we will get to where we land better
condition statements in 4.0 but probably not, as only prep work has been done
so far. With that said the plan is to improve the current conditionals, and
also add some kernel run time vars.
**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.
yeah, another one we need to get upstream. The question has been exactly what
we can get upstream before we make it available more broadly. This should be
coming within the next couple kernel releases.
**Snap**
Some snap based profile (dynamically generated by snap itself) breaks when
using with apparmor.d [0]
indeed
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.
I have talked to the snap team about this some, and locally within our own
policy we are going to work towards getting rid of unconfined as a label. Any
where it exists today with get replaced with a variable with a name that has
the semantic intent. It may get set to unconfined, but it will at least be
easier to make changes.
**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 have some ideas here, but we are going to need to do some testing to find
what the major bottle necks are. Profile loads do get serialized on a mutex
lock but that should be only held during the insert after all the unpack and
verification is done.
It will be interesting to get some actual data on the bottle neck.
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].
thanks, that is going to take awhile to digest. Hopefully there are some good
clues in it
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
