For FreeBSD, an implementation of an application isolation mechanism has been proposed, resembling the system calls plegde and unveil developed by the OpenBSD project. Isolation in plegde is achieved by prohibiting access to system calls not used by the application, while unveil selectively opens access only to specific file paths that the application can work with. A semblance of a whitelist of system calls and file paths is created for the application, and all other calls and paths are prohibited.
The difference in the analogue of plegde and unveil being developed for FreeBSD boils down to providing an additional layer that allows isolating applications without making changes to their code or with minimal modifications. It is important to note that in OpenBSD, plegde and unveil are aimed at tight integration with the base environment and are applied through the addition of special annotations in the code of each application. For ease of organizing protection, the filters allow bypassing detail at the level of individual system calls and manipulating classes of system calls (I/O, file reading, file writing, sockets, ioctl, sysctl, process execution, etc.). Access limitation functions can be called in the application code as certain actions are performed, for example, access to sockets and files can be restricted after opening the necessary files and establishing a network connection.
The author of the plegde and unveil port for FreeBSD intends to provide the ability to isolate arbitrary applications, for which the utility curtain has been proposed, allowing the application of rules defined in a separate file to applications. The proposed configuration includes a file with basic settings that define classes of system calls and typical file paths specific to certain applications (working with audio, network interaction, logging, etc.), as well as a file with access rules for specific applications.
The curtain utility can be used to isolate most unmodified utilities, server processes, graphical applications, and even entire desktop sessions. It supports the use of curtain in conjunction with isolation mechanisms provided by the Jail and Capsicum subsystems. Nested isolation is also possible, where the launched applications inherit the rules set for the parent application, supplemented by individual constraints. Some kernel operations (debugging tools, POSIX/SysV IPC, PTYs) are additionally protected using a barrier mechanism that prevents access to kernel objects created by processes other than the current or parent process.
A process can independently set up its own isolation using the curtainctl call or by utilizing the functions plegde() and unveil() provided by the libcurtain library, similar to those found in OpenBSD. To monitor blocks during the application's runtime, the sysctl 'security.curtain.log_level' is provided. Access to X11 and Wayland protocols is enabled separately by specifying the options '-X'/'-Y' and '-W' when starting curtain, but support for graphical applications is still not sufficiently stable and has a number of unresolved issues (these problems primarily manifest when using X11, while support for Wayland is significantly better implemented). Users can add additional constraints by creating local rule files (~/.curtain.conf). For example, to allow writing from Firefox to the ~/Downloads/ directory only, a section '[firefox]' can be added with the rule '~/Downloads/ : rw +'.
The implementation includes the mac_curtain kernel module for Mandatory Access Control (MAC), a set of patches for the FreeBSD kernel implementing the necessary handlers and filters, the libcurtain library for using the plegde and unveil functions in applications, the curtain utility, sample configuration files, a set of tests, and patches for some user-space programs (e.g., to utilize $TMPDIR for uniform handling of temporary files). The author intends to minimize the number of changes requiring patches to the kernel and applications wherever possible.
Source: opennet.ru
