Application Sandboxing - AGL Documentation Next Momi Navi Previous Creating a New Application 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. Next Momi Navi Previous Creating a New Application Documentation built with MkDocs using Windmill theme by Grist Labs.