7

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.

1
  • 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
    Commented Jun 16, 2019 at 8:28

2 Answers 2

6

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
  capability,
  network,
  mount,
  remount,
  umount,
  pivot_root,
  ptrace,
  signal,
  dbus,
  unix,
  file,
}

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.

1
  • 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
    Commented Oct 18, 2019 at 14:45
6

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.

2
  • 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
    Commented Dec 28, 2018 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. Commented Jul 29, 2019 at 18:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .