Recently the author of the Cosmopolitan C standard library and the Redbean platform announced through a announced, the implementation of the pledge() isolation mechanism for Linux.
It was originally developed by the OpenBSD project y allows you to selectively ban that applications access unused system calls (a kind of whitelist of system calls is formed for the application and other calls are prohibited). Unlike the syscall access control mechanisms available on Linux, such as seccomp, the pledge mechanism is designed from the ground up to be as user-friendly as possible.
The failed initiative to isolate applications in the OpenBSD base environment using the systrace mechanism demonstrated that isolation at the level of individual system calls is too complicated and time consuming.
As an alternative, pledge was proposed, which allowed to create isolation rules without going into details and manipulating prepared access classes.
For example, classes offered are stdio (input/output), rpath (read only files), wpath (write files), cpath (create files), tmppath (work with temporary files), inet (sockets network), unix (unix sockets), dns (DNS resolution), getpw (read access to user database), ioctl (ioctl call), proc (process control), exec (startup processes), and id (permission control).
The rules for working with system calls are specified in the form of annotations that include a list of allowed system call classes and an array of file paths where access is allowed. After compiling and running the modified application, the kernel takes over the job of monitoring compliance with the specified rules.
Separately, the pledge implementation for FreeBSD is being developed, which is distinguished by the ability to isolate applications without making changes to their code, while in OpenBSD the pledge call is aimed at tight integration with the base environment and the addition of annotations to the code of each one.
Pledge is like the forbidden fruit we all covet when the boss says we should use things like Linux. Why does that matter? It's because the pledge() actually makes security understandable. Linux has never really had a layer of security that mere mortals can understand.
The Linux pledge port developers took a cue from FreeBSD and instead of making code changes, they prepared an additional utility from pledge.com that allows you to apply restrictions without changing the application code. For example, to run the curl utility with access only to the stdio, rpath, inet, and threadstdio system call classes, simply run "./pledge.com -p 'stdio rpath inet thread' curl http://example.com ».
The utility works on all Linux distributions since RHEL6 and does not require root access. Additionally, based on the cosmopolitan library, an API is provided for managing restrictions in the code of C language programs, which allows, among other things, to create enclaves to selectively restrict access in relation to certain functions of the application. .
There have been a few developers in the past that have tried this. I'm not going to name names, because most of these projects were never completed. When it comes to SECOMP, online tutorials only explain how to whitelist system calls, so most people lose interest before figuring out how to filter arguments. The projects that moved forward also had oversights like allowing setuid/setgid/sticky bits to be changed. Therefore, none of the current alternatives should be used. I think this effort brings us much closer to having pledge() than ever before.
Implementation requires no kernel changes: utility constraints are translated into SECCOMP BPF rules and processed using Linux's native system call isolation mechanism. For example, calling promise("stdio rpath", 0) will convert to a BPF filter
Finally, if you are interested in knowing more about it, you can consult the details In the following link.