Skip to content

flatpak

fapp

Default profile for all flatpak applications. Ideally, this profile should be generated by flatpak itself with settings from the flatpak manifest. See abstractions/app/flatpak for more details about the security objectives.

flatpak

Profile for Flatpak. Multiple modes of operation are supported, depending on the security goals.

Security objectives

There are multiple ways to confine Flatpak (and Flatpak applications):

  1. default (wip): You trust Flatpak for application sandboxing. Flatpak (and bwrap) are confined as much as possible. However, application separation is left entirely to Flatpak. The apps are confined, but the profile purposely allows everything.

    AppArmor does not restrict anything on the application side.

  2. strict: You trust Flatpak for application sandboxing, but you would like it to be somewhat stricter in terms of access. You still want most of your applications to run without issue. AppArmor confinement goes a bit further than Flatpak:

    • System D-Bus communications are more limited than a plain dbus talk
    • Flatpak helpers such as flatpak-spawn --host are controlled: apps such as an IDE or htop will work, nothing more.

    Flatpak is confined as in default mode, but apps are confined with a generic profile (fapp), shared with all apps, that limits access to well known safe activities.

    Enabled with ${WITH_FLATPAKAPPS} == false (default)

  3. extreme (wip): Flatpak application sandboxing is a good base, but by design (usability) it is limited. You want to restrict it as much as possible, such that:

    • All D-Bus communications are more limited than a plain dbus talk
    • Flatpak helpers such as flatpak-spawn --host are blocked (apps such as an IDE or htop will not work).
    • The profile supports many more separations than default Flatpak (in terms of devices, shares, sockets and features), such that the use of broad access modes (e.g. devices/all) can be extremely limited [wip]
    • User files are controlled by AppArmor, not by the application developer [planned]

    For each app, a dedicated AppArmor profile is created. Separation between Flatpak, bwrap and apps is also cleaner and stricter (no profile stacking is required). This requires aa-flatpak to be installed, as well as a patch for both bwrap and flatpak.

    Enabled with ${WITH_FLATPAKAPPS} == true

All of these security levels are valid (including Flatpak without AppArmor at all). It is only a tradeoff between usability and security.

Overall architecture of the flatpak profiles: 

aa-flatpak                         # Generate the app profiles (`${WITH_FLATPAKAPPS} == true`)

flatpak                            # Manage the applications, the runtimes and the remotes
├── fbwrap                         # Create the sandbox, start the app (`${WITH_FLATPAKAPPS} == false`)
│   ├── fbwrap//&fapp              # Generic profile for all applications
│   ├── fbwrap//&glycin//loaders   # Image loaders (`&:glycin:loaders` on apparmor >= 5.0)
│   ├── fbwrap//&xdg-dbus-proxy    # Filter the app access to the session bus (allow any dbus)
│   └── fbwrap//&ldconfig          # Build the app library cache in the sandbox
├── bwrap                          # Create the sandbox, start the app (`${WITH_FLATPAKAPPS} == true`)
│   ├── flatpak.dbus.<appid>       # Dbus proxy profile for each applications
│   ├── flatpak.<appid>            # Application specific profile
│   ├── flatpak.build              # Run a command in a build sandbox (`flatpak build`)
│   ├── flatpak.icon-validator     # Validate the icons exported by the app
│   ├── flatpak.install            # Run the install script shipped by the app
│   ├── flatpak.ldconfig           # Build the app library cache
│   └── flatpak.trigger            # Run the scripts in /usr/share/flatpak/triggers
│       ├── &gtk-update-icon-cache # Refresh the icon cache
│       └── &update-mime-database  # Refresh the mime database
├── flatpak//&enter                # `flatpak enter`, not confined on purpose
├── flatpak//fusermount            # Mount the revokefs-fuse install cache
└── flatpak//gpg                   # Check the ostree repository signatures

flatpak-validate-icon              # Validate an icon before it is exported
flatpak-oci-authenticator          # Authenticate on OCI remotes (`org.flatpak.Authenticator.Oci`)
flatpak-portal                     # Spawn commands on the host (`org.freedesktop.portal.Flatpak`)
flatpak-session-helper             # Session services for the sandbox (`org.freedesktop.Flatpak`)
├── flatpak-session-helper-app     # App binary run on the host by the helper
│   └── udevadm                    # Query the host devices
├── p11-kit                        # Forward the host PKCS#11 modules to the sandbox
└── pkexec                         # Ask for privileges through polkit
flatpak-system-helper              # System wide install (`org.freedesktop.Flatpak.SystemHelper`)
├── bwrap                          # Sandbox running the deploy triggers
│   ├── &gtk-update-icon-cache     # Refresh the icon cache
│   ├── &update-desktop-database   # Refresh the desktop file database
│   └── &update-mime-database      # Refresh the mime database
├── bwrap_apps                     # Sandbox running the app install script
└── gpg                            # Check the ostree repository signatures