Skip to content

Abstractions

Abstractions enable resources from one profile to be shared with another and with the system. The table below lists currently supported interfaces, with links to further details for each interface.

This project and the official apparmor-profiles project provide a large selection of abstractions to be included in profiles. They should always be used as they target wide compatibility across hardware and distributions while only allowing the bare minimum access.

Example

For instance, to allow download directory access instead of read and write permissions: 

owner @{HOME}/@{XDG_DOWNLOAD_DIR}/{,**} rw,

You should write: 

include <abstractions/user-download-strict>

Warning

https://snapcraft.io/docs/supported-interfaces

find apparmor.d/abstractions/ -maxdepth 1 -type f | wc -l

Architecture

Abstraction are structured in layers as follows:

  • Layer 0

    For core atomic functionalities.

    This resource uses mesa, openssl, bash-strict, gtk-strict...

  • Layer 1

    For generic access.

    This program needs this resource. nameservice-strict, authentication, ...

  • Layer 2

    For common kind of program.

    This program kind is a game, an electron app

  • Layer 3

    For application

    This program is sudo, firefox

System abstractions

In addition to the above layers, there are abstractions that provide access to system specific part of the system resources.

To use the terminology detailed earlier, these abstractions are layer -1

  • Dbus

    Specific to a dbus interface

    This interfaces needs bus/system/org.freedesktop.ModemManager1 ...

  • sys

    sys filesystem access

    This program needs/has this resource. sys/input, sys/hmon, ...

  • udev

    For udev device access

    This program kind is udev/input

  • dev

    For device access

    This program kind is /dev/input