The abstractions folder has many reusable abstractions that can be included in profiles to reduce code duplication and allow for common accesses to be granted easily.
Choosing abstractions with less privilege is generally preferred. Sometimes abstractions are split into a more restricted reduced set of permissions ending in -strict and a broader set of permissions. Eg. nameservice-strict and nameservice.
Currently abstractions can't specify their dependency on variables in the tunables directory. If you encounter errors about undefined variables after including an abstraction, you will need to find the correct tunables file to include in the preamble block of the profile.
Some of the more common abstractions include
-
abstractions/base
: basic accesses to things like system shared libraries that would be expected to be used by any program. Production profiles generally should include this. -
abstractions/nameservice
: accesses required to resolve name resolution queries in a variety of situations (e.g. direct DNS queries, communicating with libnss-libvirt or kerberos, etc.). -
abstractions/nameservice-strict
: accesses required for a much more limited set of name resolution queries, primarily by accessing files like/etc/resolv.conf
. Try using this abstraction first before the more permissiveabstractions/nameservice
abstraction. -
abstractions/private-files
: user private files that usually should not be accessed. This abstraction is useful as a carve-out for applications that may legitimately need to access files anywhere but that still would generally not be expected to e.g. write to files in@{HOME}/.bin
. -
abstractions/private-files-strict
: a more strict version of the above that also blocks accesses to e.g. SSH keys and FireFox browser configuration files. -
abstractions/python
: accesses used by the Python runtime. -
abstractions/perl
: accesses used by the Perl runtime. -
abstracitons/consoles
: accesses used by TUI programs that use features of TTY consoles, such as shells.