I like this. I'd try to keep the permission sets as small, limited, and simple as possible though.

> I'd try to keep the permission sets as small and simple as possible though.

You've described OpenBSD in general. I recommend a deeper dive - it's fantastically refreshing, how simple yet functional an OS can be.

Same for FreeBSD. Incredibly code-stable and well-documented by Linux standards.

I often use the FreeBSD Handbook as an example of first-party documentation done right, and that's only possible because of deliberately limited "churn for churn's sake". The kinds of regular code rot and attrition that Linux suffers just does not take place on BSD systems because if you contribute something new you're expected to make your thing mesh with the ecosystem, they don't tolerate the "I'm gonna churn everyone's environments because my version is 10% better than the existing one" that tends to take place on Linux.

As an example, the amount of init systems that Ubuntu has gone through over the last 20 years is completely insane by BSD standards. They've gone from sysvinit to upstart to systemd. You don't have people ripping out the graphics and audio subsystems and doing total rewrites, either. It's nuts that a lot of Linux people don't even realize that it doesn't have to be that way - that's not "just how maintenance is supposed to work", that's a bunch of incredibly bad behavior on the parts of distros and Poettering specifically that has become highly normalized and overlooked. Maintenance shouldn't be breaking things like that. "we never break userland" doesn't have to be a suicide pact either - BSD has actually maintained a much more stable ABI than the linux kernel without crystallizing a bunch of shitty bug-compatibility stuff like Linux is doing either. It's all insanely stable and competent and professional by linux standards.

If I was developing a product for true long-term support, with the minimum possible engineering effort devoted to fighting churn, BSD would be at the top of the list.

And with all that beauty, FreeBSD is not something I would [nowdays] look into as base OS for hosting my services and products. It means something, probably something about humans.

Netflix uses FreeBSD for their CDN/edge caches - it was consistently more performant both in benchmarks and with real-world workloads.

Yeah, that's quite interesting reading from them, some sort of specialized appliance really.

I'm and the average Joe around me, totally far from Netflix's task of packing bytes from disk to network. Simple 2vCPU VPS serving 4GBit without being saturated on system resource level is quite often much more than enough. Extra note - it's not even using kTLS.

Moreover, even for Netflix, noting they know FreeBSD in and out, do you think/have info on using FreeBSD as base OS beyond distribution level - running applications/services in particular?

I've quickly checked on their repos like https://github.com/Netflix/conductor and it smells like they use containers/Docker, which doesn't work on FreeBSD => I'm in very much doubts it's OS of choice for them.

What attracted me to Linux so long ago is what ultimately drove me away. I now apply it only as needed because it's no longer simple ("stable" over the timescales I'm interested in) as a project, and it's not moving towards any type of consistency.

If you read "rolling stones gather no moss" to mean "keep moving or risk becoming obsolete", choose Linux. If you understand it as "change for change's sake prevents the achievement of mastery", go with a BSD.

I think @jart has been porting it to Linux https://justine.lol/pledge/ .

Indeed! If your dependencies are able to be command line programs that are shell scripted together, then you can in fact have an access policy on a per-dependency basis, using the pledge.com program linked on my website. So shell scripters rejoice.

But it gets better. If you build Python in the Cosmopolitan Libc repository:

    git clone https://github.com/jart/cosmopolitan
    cd cosmopolitan
    build/bootstrap/make.com -j8 o//third_party/python/python.com

Then you can use cosmo.pledge() directly from Python.

    $ o//third_party/python/python.com
    Python 3.6.14+ (Actually Portable Python) [GCC 9.2.0] on cosmo
    Type "help", "copyright", "credits" or "license" for more information.
    >>: import cosmo, socket
    >>: cosmo.pledge('stdio rpath wpath tty', None)
    >>: print('hi')
    hi
    >>: socket.socket()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/zip/.python/socket.py", line 144, in __init__
        _socket.socket.__init__(self, family, type, proto, fileno)
    PermissionError: [Errno 1] EPERM/1/Operation not permitted

Since we didn't put "inet" in the pledge, you can now be certain your PyPi deps aren't spying on you or uploading your bitcoin wallet to the cloud. You can even use os.fork() to rapidly put each dependency in its own process, then call cosmo.pledge() afterwards to grant each component of your app its own maximally restrictive policy.

Cosmopolitan Python also ports OpenBSD's unveil() system call to Linux too. For example, to disallow all file system access, just call cosmo.unveil(None, None). You need a very recent version of Linux though. For instance, I use unveil() in production on GCE but I had to apt install linux-image-5.18.0-0.deb11.4-cloud-amd64 in order for Landlock LSM to be available to use unveil().

I thought the thread model of pledge/unveil was to restrict a program that you are writing, but that you couldn't wrap around other program in a safe way.

That is, you can protect your own program from doing network stuff because of incorrect input, but you can't use it to sandbox another program.

See this thread: https://marc.info/?t=162367803300003&r=1&w=2 and this mail about sandboxing: https://marc.info/?l=openbsd-tech&m=162367954705721&w=2

You can, if you use pledge() and unveil() on Linux. SECCOMP and Landlock use a monotonically decreasing permissions model. It's inherited across exec(). This is a good thing. OpenBSD devs don't need it because they built their own hermetic system. They're more afraid of having their servers compromised remotely than they are of programs they've installed locally. The tradeoff is you can't use pledge() and unveil() to build your own SSH server on Linux, since SSH needs to shed restrictions when launching a shell. But the benefit is you can safely leverage more code written by strangers on the Internet, which is what Linux is all about.

I thought of OpenBSD too since it includes Perl modules for OpenBSD::Pledge and OpenBSD::Unveil. Now I'm wondering if I can get something to work where these are used before importing CPAN modules to reduce the damage of potentially hostile modules.