Posted by sunshine-o 4/3/2025
A need for a default-deny-all and then select what a process needs is the better security granularity.
This default-ALLOW-all is too problematic for today's (and future) security needs.
Cuts down on the compliance paperworks too.
> The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).
Which permissions and authorizations can be delegated?
DAC is the out of the box SELinux configuration for most Linux distros; some processes are confined, but if the process executable does not have the necessary extended filesystem attribute labels the process runs unconfined; default allow all.
You can see which processes are confined with SELinux contexts with `ps -Z`.
MAC is default deny all;
MAC: Mandatory Access Control: https://en.wikipedia.org/wiki/Mandatory_access_control
Does not help when the SELinux source text file is not buildable by function/procedure axiom: it is at its grittiest granularity, which ironically is the best kind of security, but only if composed by the most savviest SELinux system admins.
Often requires full knowledge of any static/dynamic libraries and any additional dynamic libraries it calls and its resource usages.
Additional frontend UI will be required to proactively determine suitability with those dynamic libraries before any ease of SELinux deployment.
For now, it is a trial and error in part on those intermediate system admins or younger.
> [ audit2allow, https://stopdisablingselinux.com/ ]
Applications don't need to be compiled with selinux libraries unless they want to bypass CLI tools like chcon and restorecon (which set extended filesystem attributes according to the system policy; typically at package install time if the package provenance is sufficient) by linking with libselinux.
1) It enables better separation of concerns, Twelve-Factor App style. For example, user-installed programs no longer need to connect to a logging daemon or execute a complex daemonization dance [1]. They can just run like a normal command-line program and dump logs to stderr.
2) It cuts down on integration problems, shell script glue, and the amount of different config syntaxes you have to know. Its architecture is modular with over 100 different binaries, so you can still pick-and-choose components and do privilege separation, but because these components are all coming from the same vendor, you know they're going to work well together.
3) It can do certain things far more reliably because it's willing to use Linux-specific APIs. For example, thanks to cgroups v2, it can supervise a process correctly no matter what kind of weird forking strategy the process is using.
Since this project is intended to be compatible across Unix-like systems, it won't be able to use Linux-specific APIs, so advantage 3 is gone. It looks like it dropped many components of systemd, so advantage 2 is partially gone too. Is this project just about getting some cross-cutting concerns into the init system and having better scheduling of service startup?
[1] https://www.freedesktop.org/software/systemd/man/latest/daem...
Pick the parts you want in your BSD and clone it. Don't port.
It's not just systemd that is a linuxism, but it relies heavily on other linuxisms like dbus. Which does work on BSD, sure. But it shouldn't be part of the core system which an init daemon obviously is.
What I like about FreeBSD is the rc.local idea which is a bit like Nix.
In other words - to make it simple - get the fuck out of my lawn with that shit.