Full system policy (FSP)

Overview¶

The default mode of apparmor.d is the more advanced confinement configuration we can achieve while being as simple as installing a package and doing some minor configuration on your system. By design, a full system confinement does not work this way. Before enabling you need to consider your use case and security objective.

Particularly:

• Every system application will be blocked if they do not have a profile.
• Any non-standard system app need to be explicitly profiled and allowed to run. For instance, if you want to use your own proxy or VPN software, you need to ensure it is correctly profiled and allowed to run in the systemd profile.
• Desktop environment must be explicitly supported, your UI will not start otherwise. Again, it is a feature.
• In FSP mode, all sandbox managers must have a profile. Then user sandboxed applications (flatpak, snap, etc) will work as expected.
• PID 1 is the last program that should be confined. It does not make sense to confine only PID. All other programs must be confined first.
• User interactive shell must be confined. This is done through PAM and Role Based Access Control (RBAC).

Installation¶

This feature is only enabled when the project is built with just fsp. Early policy load must also be enabled. Once apparmor.d has been installed in FSP mode, it is required to reboot to apply the changes.

In /etc/apparmor/parser.conf ensure you have:

write-cache
cache-loc /etc/apparmor/earlypolicy/
Optimize=compress-fast

-  just complain
+  just fsp-complain

  override_dh_auto_build:
-     just complain
  override_dh_auto_build:
+     just fsp-complain

  override_dh_auto_build:
-     just complain
  override_dh_auto_build:
+     just fsp-complain

   %build
-  just complain
   %build
+  just fsp-complain

Systemd¶

The profiles dedicated for full system policies are maintained in the _full group. Systemd (as PID 1) is the entrypoint of the system, thus in FSP mode, it is also the entry point of the confinement.

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 mount operations from services
    ├── sd-umount                      # Handles unmount operations 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

Design rationale¶

The systemd profiles design aims at providing a flexible and secure confinement for systemd and its services while addressing several challenges:

• 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 handled stacked profiles.
• Most additions need to be done in the sd/sdu profile, not in systemd/systemd-user.
• Dedicated sd-mount / sd-umount profiles for most mount from the unit services.

Profile systemd¶

The profile for systemd (PID 1) does not specify an attachment path because it is directly loaded by systemd thanks to the early policy feature.

Systemd is (kind of obviously) a highly privileged program. The purpose of this profile is to transition to other less privileged program as soon as possible. It only allows transition to two kinds of profiles:

• The systemd executor (profile named sd) it is the systemd internal service starter and config handler.
• The system generators (profiles named systemd-generators-*), they are used at boot time to generate systemd unit files based on the current system configuration.

Profile sd¶

sd is a profile for SystemD-executor run as root, it is used to run all services files and to encapsulate stacked services profiles (hence the short name to keep security attribute easy to read). It aims at reducing the size of the main systemd profile.

In an even more secure environment, it can also be used to strictly limit the list of allowed services that can be started by systemd(1).

1. Work in Progress

/usr/lib/systemd/system/*.service
/usr/lib/systemd/system-environment-generators/*

Profile systemd-user¶

sd allow transition to systemd-user, the profile for systemd --user. It is only intended to handle user based sessions.

Similarly to systemd, it only allows transition to two kinds of profiles:

• The systemd executor (profile named sdu) it is the systemd internal user service starter and config handler.
• The user generators, they are used at user session start to generate systemd unit files based on the current user configuration.

/usr/lib/systemd/user-environment-generators/*
/usr/lib/systemd/user-generators/*

Profile sdu¶

sdu is a profile for SystemD-executor run as User, 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.

Role Based Access Control (RBAC)¶

In FSP, interactive shell from the user must be confined. This is done through pam_apparmor. It provides Role-based access controls (RBAC) that can restrict interactive shell to well-defined role. The role needs to be defined. This project ship with a default set of roles, but you can create your own. The default roles are:

• user: This is the default role. It is used for any user that does not have a specific role defined. It has access to the user home directory and other sensitive files.

• admin: This role is used for any user that has administrative access. It has access to the system files and directories, but not to the user home directory.

The profiles dedicated for the roles definition are maintained in the _roles group.