Being very new to apparmor, would just like to start by placing some simple 1 line restriction on a program. And leave everything else as-is. Also, for other reasons it's not possible for me to easily profile this specific executable. It is a part of the window manager that is started / kocked off by GDM / gnome session during user login.

Hoping to achieve something a bit like this:

# Last Modified: Fri Dec 28 09:20:30 2018
#include <tunables/global>

/usr/bin/budgie-panel {

  #include <abstractions/base>

  # allow all rules first
  allow *,

  # Then deny 1 specific dbus bind access
  deny dbus bind name=org.freedesktop.Notifications,


But is the allow *, a correct syntax for 'allow everything', in my apparmor profile? Cannot find a clear documentation explaining about this.

  • Just to explain the use-case a bit more clearly: We know apparmor is typicalls meant as a tool for security. However that is not it's only useful effect upon running applications! In this case, we just want to limit the capabilities of the launched application on the local system. Not for security reasons whatsoever, just simply to stop it from grabbing and hogging a shared resource (a local DBUS endpoint), when it starts up... thus freeing up the resource for the other software, for which I do want to use for receiving the Toast notifications. – Dreamcat4 2 days ago

This is not the right approach.

In general, blacklisting is a poor basis for a security policy - it should be based on whitelisting - and the syntax of AppArmor is predicated on this. To that end, you should start with no specifics in the profile, but set the profile action to complain instead of enforce. You can set this in the profile (flags=(complain)) or using the aa-complain command. Then the specific directives to permit an operation become redundant.

I believe the authoritative documentation is that published by SuSE. But, briefly, for file access the config format is:

<object> <permissions>,

Note that the globbing in object (if its a path) is slightly different from what you may be familiar with at the command line. There's more dbus specific stuff here.

  • 1
    Thank you for your answer. It is acknowledged that this approach is not recommended for best security practices. In regards to complain - that is not going to work here because then the deny dbus bind rule will no longer be enforced either. Which is entirely the sole objective / only goal being sought by creating this new apparmor profile. complain is however the recommended mechanism for profiling in order to gather whitelist rules. So mentioning its usage is relevant to help any newcomer. – Dreamcat4 Dec 28 '18 at 11:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.