One of the motivations for leveraging systemd in applaunchd was to allow the use of its advanced features such as sandboxing, system call filtering, process limits, and Linux CGroup configuration via slices. The scope of potential systemd configurations involving these options is broad, and so far AGL has focused on providing some simple examples of basic sandboxing integrated with the application templates discussed above.

Network Access Restriction¶

The systemd PrivateNetwork service configuration option can be used to disable network access for the service started by a unit file. The applaunchd packaging installs a systemd drop-in configuration file named no-network.conf in the directory /usr/lib/systemd/system/sandboxing that may be used to disable network access with PrivateNetwork. To use it, no-network.conf should be symlinked in an appropriate unit file drop-in override directory per systemd naming expectations (see systemd unit file man page). The following is a BitBake recipe snippet showing installation of the drop-in for an application named foo that is using the generic application template:

...

inherit agl-app

AGL_APP_NAME = "Foo"

do_install() {
    # Enable systemd sandboxing override as a demonstration
    install -d ${D}${systemd_system_unitdir}/agl-app@${AGL_APP_ID}.service.d/
    ln -sf ${systemd_system_unitdir}/sandboxing/no-network.conf ${D}${systemd_system_unitdir}/agl-app@${AGL_APP_ID}.service.d/
}

FILES:${PN} = " \
    ${sysconfdir}/systemd/system/agl-app@${AGL_APP_ID}.service.d \
"

...

This results in a /usr/lib/systemd/system/agl-app@foo.service.d/no-network.conf symlink being created in the foo packaging, disabling network access when foo is started by applaunchd or directly via systemctl on the command line.

Private Temporary Directories¶

The systemd PrivateTmp service configuration option can be used to prevent access to the host /tmp and /var/tmp directories for the service started by a unit file. The service will instead have private temporary mounts of these directories in a new mount namespace. The applaunchd packaging installs a systemd drop-in configuration file named private-tmp.conf in the directory /usr/lib/systemd/system/sandboxing that may be used to create private temporary directory mounts with PrivateTmp. To use it, private-tmp.conf should be symlinked in an appropriate unit file drop-in override directory per systemd naming expectations (see systemd unit file man page). See above for an example BitBake recipe snippet showing installation of a drop-in file when using the generic application template.

Other Sandboxing Options¶

In addition to the above, some other notable systemd sandbox options worth further consideration for applications include:

• PrivateDevices
  This option could be used to remove access to device files in /dev for applications that do not require them, but it is likely that DeviceAllow may also need to be used to enable functionality in some applications.
• ProtectSystem
  The default and full modes of this option likely can be enabled with little impact to most applications, as they should not need write access to the directories that are made read-only. Using the strict option would need investigation into interactions with usage of directory hierarchies like /run.
• ProtectHome
  This option seems worthwhile if the system ends up with more than one active user for running applications, but interactions with default application caching and configuration locations needs to be investigated. It is likely that enforcing use of locations outside of /home for these would need to be settled upon and documented for application developers. For example using the XDG directory scheme similar to the previous AGL application framework.
• ReadWritePaths, etc.
  These options provide a more fine-grained approach to some of the above ones, and could be used to enable something like an application only seeing its own files and the contents of a specific set of directories like /etc and /usr/lib. Implementing such would likely require settling on a custom application installation hierarchy as was done in the previous AGL application framework.

The above list is not exhaustive, and does not include some other likely possibilities involving system call filtering and resource limits. Future AGL releases may expand the examples provided with applaunchd along these lines.