Skip to content

_full

sd

Part of the systemd (as PID 1) profile.

sd is a profile for S**ystem**D-executor run as root, it is used to run all services files and to encapsulate stacked services profiles (hence the short name).

It aims at reducing the size of the systemd profile.

Info

Distributions and other programs can add rules in the usr/sd.d directory

sd-mount

Part of the systemd (as PID 1) profile.

sd-mount is a subprofile of sd responsible to handle mounting operation.

Info

Distributions and other programs can add rules in the usr/sd-mount.d directory

sd-umount

Part of the systemd (as PID 1) profile.

sd-umount is a subprofile of sd responsible to handle unmounting operation.

Info

Distributions and other programs can add rules in the usr/sd-umount.d directory

sdu

Part of the systemd-user profile.

sdu is a profile for S**ystem**D-executor run as **U**ser, it is used to run all services files and to encapsulate stacked services profiles (hence the short name).

It aims at reducing the size of the systemd-user profile.

Info

Distributions and other programs can add rules in the usr/sdu.d directory

systemd

Profile for systemd (PID 1), it does not specify an attachment path because it is directly loaded by systemd.

Danger

Only use this profile with a fully configured system. Otherwise it WILL break your computer. See https://apparmor.pujol.io/full-system-policy/.

Info

Distributions and other programs can add rules in the usr/systemd.d directory

Overall architecture of the systemd profiles:

systemd                                # PID 1, entrypoint, requires "Early policy"
├── systemd                            # To restart itself
├── systemd-generators-*               # Systemd system and environment generators
└── sd                                 # Internal service starter and config handler, handles all services
    ├── Px or px,                      # Any service with profile
    ├── Px ->                          # Any service without profile defined in the unit file (see systemd/full/systemd)
    ├── &*                             # Stacked service as defined in the unit file (see systemd/full/systemd)
    ├── sd-mount                       # Handles all mounts from services
    ├── sd//systemctl                  # Internal system systemctl
    └── systemd-user                   # Profile for 'systemd --user'
        ├── systemd-user               # To restart itself
        ├── systemd-user-generators-*  # Systemd user and environment generators
        └── sdu                        # Handles all user services
            ├── Px or px,              # Any user service with profile
            ├── Px ->                  # Any user service without profile defined in the unit file (see systemd/full/systemd)
            ├── &*                     # Stacked user service as defined in the unit file (see systemd/full/systemd)
            └── sdu//systemctl         # Internal user systemctl

Advantages:

  • Differentiate systemd (PID 1) and system --user
  • Keep systemd and systemd-user as mininal as possible, and transition to less privileged profiles.
  • Allow the executor profiles to handle stacked profiles.
  • Most additions need to be done in the sd/sdu profile, not in systemd/systemd-user.
  • Dedicated sd-mount profile for most mount from the unit services.

Work in Progress

This profile stack can be changed to provide a more controlled environment:

  • No global allow anymore: in high security environments, we must manage the list of program/service that can be started by systemd and ensure that they are all listed and confined. Programs not listed will not be able to start.
  • Outside common systemd service, the list may have to be automatically generated at install time, in /etc/apparmor.d/usr/systemd.d/exec

systemd-user

Profile for 'systemd --user', not PID 1 but the user manager for any UID. It does not specify an attachment path because it is intended to be used only via px -> systemd-user exec transitions from the systemd profile.

Danger

Only use this profile with a fully configured system. Otherwise it WILL break your computer. See https://apparmor.pujol.io/full-system-policy/.

Info

Distributions and other programs can add rules in the usr/systemd-user.d directory