It was made known that an implementation has been proposed a application isolation mechanism for FreeBSD, which is reminiscent of the fold and unveil system calls developed by the OpenBSD project.
Isolation in plegde is done by prohibiting access to system calls that are not used by the application and disclosing by selectively opening access only to certain file paths that the application can work with. 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 folded and unveiled, developed for FreeBSD, it boils down to providing an extra layer that allows you to isolate applications with no or minimal changes to their code. Remember that in OpenBSD plegde and unlock aim for 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 details at the level of individual system calls and to manipulate classes of system calls (input/output, file read, file write, sockets, ioctl, sysctl, start of processes, etc). Access restriction functions can be called in 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 fold and reveal port for FreeBSD intended 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 (work with sound, networks, logging, etc.), as well as a file with access rules for applications specific.
The curtain utility can be used to isolate most utilities, server processes, graphical applications, and even entire desktop sessions that have not been modified. Sharing curtain with the isolation mechanisms provided by the Jail and Capsicum subsystems is supported.
As well it is possible to organize nested isolation, when launched applications inherit the rules set by the parent application, supplementing them with separate constraints. Some kernel operations (debugging tools, POSIX/SysV IPC, PTY) are additionally protected by a barrier mechanism that prevents access to kernel objects created by processes other than the current or parent process.
A process can configure its own isolation by calling curtainctl or by using the plegde() and unveil() functions provided by the libcurtain library, similar to OpenBSD's. The 'security.curtain.log_level' sysctl 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 starting curtain, but support for graphical applications is not yet sufficiently stabilized and has a series of unresolved issues (problems appear mainly when using X11, and Wayland support is much better). Users can add additional restrictions by creating local rules files (~/.curtain.conf). For example,
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 necessary drivers and filters, the libcurtain library for using plegde and revealed functions in applications, the utility curtain, shows configuration files, a suite of tests, and patches for some user-space programs (for example, to use $TMPDIR to unify working with temporary files). Whenever possible, the author tries to minimize the number of changes that require patching the kernel and applications.
Finally if you are interested in knowing more about it, you can check the details In the following link.