_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
systemdand 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/sduprofile, not insystemd/systemd-user. - Dedicated
sd-mountprofile 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