Application allowlisting is the practice of specifying an index of approved applications or executable files that are permitted to run on a system by a specific user. This is often used on a multi-user system or some kind of a shared hosting server, where multiple users exist and they have to be given limited permissions, so that they can only run approved applications on the shared system.
Note: A lot of external documentation uses the term "whitelist" in the place of allowlist and "blacklist" in the place of denylist. Red Hat is trying to be more inclusive by eradicating problematic language.
Red Hat Enterprise Linux (RHEL) and many other distributions have SELinux available, which can be used to effectively block applications which are not explicitly allow listed, and commercial products are also available. However technologies like SELinux are designed to control application behaviour but do not know which applications are trusted. Therefore SELinux is complementary to other technologies because they handle different aspects of system security.
One way to implement application allowlisting is by permitting applications that are known by some reputation source to execute or open certain files. Applications that are unknown by the reputation source are not allowed to execute. Currently, reputation sources could be the RPM databases, or an admin defined list of trusted files. Red Hat Enterprise Linux 8 ships the File Access Policy Daemon (fapolicyd) application allowlisting daemon.
Configuring fapolicyd
There are two policy files which are shipped by default in RHEL 8. The known-libs policy is designed to only block execution of untrusted files while only allowing trusted libraries. This provides good performance while ensuring that there is not much interference by the daemon.
The restrictive policy is designed to be as safe as possible. It's intended to block execution via the runtime linker and only allow execution by trusted ELF and python programs. It also enforces that only trusted libraries are allowed. It blocks execution by other languages and must be explicitly enabled.
Each of these policies can be tweaked to suit company policy requirements. More details about various configuration options are available on the Red Hat Product Documentation page.
How it actually works
Fapolicyd uses the FAN_OPEN_EXEC_PERM fanotify event from the kernel. The fanotify API provides notification and interception of filesystem events. Events of FAN_OPEN_EXEC_PERM type will be generated when a file has been opened by using either execve(), execveat(), or uselib() system calls.
When a program opens a file or calls execve, that thread has to wait for fapolicyd to make a decision. To make a decision, fapolicyd has to look up information about the process and the file being accessed. Each system call fapolicyd makes will slow down the system. This may introduce some performance issues, especially when the policy file is quite large. Various methods like caching are used to increase performance. This diagram broadly summarizes the way fapolicyd works.
Some other things to consider
Managing trust
Fapolicyd uses lmdb as a backend database for its trusted software list. You can find this database in /var/lib/fapolicyd/
. This list gets updated whenever packages are installed by yum
, by a plugin. If packages are installed by rpm
instead of yum
, fapolicyd does not get a notification. In that case, you would also need to tell the daemon that it needs to update the trust database. This is done by running fapolicyd-cli
and passing along the --update
option. Also, if you add or delete files from the admin defined file trust list, fapolicyd.trust, then you will also have to run the fapolicyd-cli
utility.
How is file integrity check maintained?
Version 0.9.5 and later supports three modes of integrity checking. When integrity checking is enabled, fapolicyd will decide not only if the file is this trusted or not, but also if the file has been tampered with. If that is the case, then it will deny access to the file/executable. The first integrity mode is based on file size. In this mode, fapolicyd will take the size information from the trust db and compare it with the measured file size. This test incurs no overhead since the file size is collected when establishing uniqueness for caching purposes. This mode is intended to detect accidental overwrites as opposed to malicious activity where the attacker can make the file size match.
The second mode is based on using Integrity Measurement Architecture (IMA) to calculate SHA256 hashes and make them available through extended attributes. This incurs only the overhead of calling fgetxattr which is fast since there is no path name resolution. The file system must support i_version. For XFS, this is enabled by default. For other file systems, this means you need to add the i_version mount option. In either case, IMA must be set up appropriately.
The third mode is where fapolicyd calculates a SHA256 hash of the file itself and compares that with what is stored in the trust db.
Why not SELinux for application allowlisting?
SELinux is modeling how an application behaves. It is not concerned about where the application came from or whether it's known to the system. Basically, anything in /bin
gets bin_t
type by default which is not a very restrictive label. MAC systems serve a different purpose than application allow listing. Fapolicyd by design cares solely about if this is a known application/library. These are complementary security subsystems.
In conclusion fapolicyd can be an effective tool for allowlisting applications. But like any other security technology, it should be used in conjunction with several other options like SELinux, and good system configuration to provide better overall security of systems.
À propos de l'auteur
Huzaifa Sidhpurwala is a Principal Product Security Engineer with Red Hat and part of a number of upstream security groups such as Mozilla, LibreOffice, Python, PHP and others. He speaks about security issues at open source conferences, and has been a Fedora contributor for more than 10 years.
Contenu similaire
Parcourir par canal
Automatisation
Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements
Intelligence artificielle
Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement
Cloud hybride ouvert
Découvrez comment créer un avenir flexible grâce au cloud hybride
Sécurité
Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies
Edge computing
Actualité sur les plateformes qui simplifient les opérations en périphérie
Infrastructure
Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde
Applications
À l’intérieur de nos solutions aux défis d’application les plus difficiles
Programmes originaux
Histoires passionnantes de créateurs et de leaders de technologies d'entreprise
Produits
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Services cloud
- Voir tous les produits
Outils
- Formation et certification
- Mon compte
- Assistance client
- Ressources développeurs
- Rechercher un partenaire
- Red Hat Ecosystem Catalog
- Calculateur de valeur Red Hat
- Documentation
Essayer, acheter et vendre
Communication
- Contacter le service commercial
- Contactez notre service clientèle
- Contacter le service de formation
- Réseaux sociaux
À propos de Red Hat
Premier éditeur mondial de solutions Open Source pour les entreprises, nous fournissons des technologies Linux, cloud, de conteneurs et Kubernetes. Nous proposons des solutions stables qui aident les entreprises à jongler avec les divers environnements et plateformes, du cœur du datacenter à la périphérie du réseau.
Sélectionner une langue
Red Hat legal and privacy links
- À propos de Red Hat
- Carrières
- Événements
- Bureaux
- Contacter Red Hat
- Lire le blog Red Hat
- Diversité, équité et inclusion
- Cool Stuff Store
- Red Hat Summit