An implementation of an application isolation mechanism has been proposed for FreeBSD, reminiscent of the plegde and unveil system calls developed by the OpenBSD project. Isolation in plegde is carried out by prohibiting access to system calls that are not used in the application, and in unveiling through selective opening of access only for certain file paths with which the application can work. For the application, a kind of white list of system calls and file paths is formed, and all other calls and paths are prohibited.
The difference between plegde and unveiled, developed for FreeBSD, comes down to providing an additional layer that allows you to isolate applications without making changes to their code or with minimal changes. Recall that in OpenBSD, plegde and unveil are aimed at tight integration with the base environment and are implemented by adding special annotations to the code of each application. To simplify the organization of protection, filters allow you to avoid detailing at the level of individual system calls and manipulate the classes of system calls (input / output, reading files, writing files, sockets, ioctl, sysctl, process startup, etc.). Access restriction functions can be called in the application code as certain actions are performed, for example, access to sockets and files can be closed after opening the necessary files and establishing a network connection.
The author of the port of plegde and unveiling for FreeBSD intends to provide the ability to isolate arbitrary applications, for which the curtain utility is proposed, which allows applying rules defined in a separate file to applications. The proposed configuration includes a file with basic settings that define the classes of system calls and typical file paths specific to certain applications (working with sound, 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. Sharing curtain with the isolation mechanisms provided by the Jail and Capsicum subsystems is supported. It is also possible to organize nested isolation, when launched applications inherit the rules set by the parent application, supplementing them with separate restrictions. Some kernel operations (debugging tools, POSIX/SysV IPC, PTYs) are additionally protected by a barrier mechanism that prevents access to kernel objects created by processes other than the current or parent.
A process can set up its own isolation by calling curtainctl or by using the plegde() and unveil() functions provided by the libcurtain library, similar to those from OpenBSD. The sysctl 'security.curtain.log_level' is provided to track locks while the application is running. Access to the X11 and Wayland protocols is enabled separately by specifying the β-Xβ/β-Yβ and β-Wβ options when launching the curtain, but support for graphical applications is not yet sufficiently stabilized and has a number of unresolved problems (problems mainly appear when using X11 , and Wayland support is much better). Users can add additional restrictions by creating local rules files (~/.curtain.conf). For example, to allow writing from Firfox only to the ~/Downloads/ directory, you can add the "[firefox]" section 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 with the implementation of the necessary handlers and filters, the libcurtain library for using plegde and unveiled functions in applications, the curtain utility, sample configuration files, a set of tests and patches for some programs in user space (for example, to use $TMPDIR to unify work with temporary files). Whenever possible, the author intends to minimize the number of changes that require application of patches to the kernel and applications.
Source: opennet.ru