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 Jun 16 '19 at 8:28

But is the allow *, a correct syntax for 'allow everything'

Correct syntax for allow everything looks like:

profile DAC /path/to/exec {
  # Allow all rules

Actually, there are two rules more:

  1. rlimit (AppArmor can set and control the resource limits associated with a profile)
  2. change_profile (control which permissions for which profiles a confined task can transition to)

But its no meaning in this particular case.

| improve this answer | |
  • Thanks Dude!!! Indeed I was trying this last week, and can confirm that allow *, is parsed as an incorrect syntax by apparmor and then the whole profile file is rejected. So now I can try this way instead, and perhaps it should work better. – Dreamcat4 Oct 18 '19 at 14:45

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.

| improve this answer | |
  • 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
  • 1
    @symcbean I would downvote if I could. AppArmor (AA) does not permit/enable anything that the process could not do if AA was not enabled (correct me if I’m wrong), so allowing everything in AA and narrowing permissions down is not worse than not enabling AA at all, if not even much better, IMHO. – Bora M. Alper Jul 29 '19 at 18:37

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.