upvote
Anyone relying on a 30+ year old monolith kernel written in C to not have some exploitable LPEs lurking should stay in basket weaving and out of sysadmin.
reply
Yep.

You should treat any system where non-admins regularly login as basically insecure/owned and rig your architecture appropriately.

TBH -- I don't have any of these kinds of boxes anymore. Who is really running anything like this in 2026 and for what purpose?

reply
Not necessarily FreeBSD, but for Linux this applies to most universities with a CS program, I think.

The systems should be cut off from sensitive administrative data, but a malicious student would at the very least have access to the other students' data with an LPE.

reply
>> monolith kernel written in C

> Who is really running anything like this in 2026 and for what purpose?

Am I parsing your question correctly?

reply
No, I worded it badly. See below.
reply
Stability of ecosystem. No systemd. Native ZFS. Jails over Docker. Been using it for 20+ years and it’s my preferred server OS.
reply
No, I mean do you run FreeBSD boxes where users who should not ever assume root access actually login to do tasks?

My point is that if you do, you probably shouldn't run, for e.g applications which need production db credential, or hold sensitive data on these boxes, or .. whatever.

Edit: I use FreeBSD extensively, for various things -- but shell access to them is restricted to the sysadmins..

reply
Hard to tell about FreeBSD, it's basically extincted, but think of webhosting servers, wordpress, cPanel/Plesk and alike.

often it's ssh'able with things like rbash and other restrictions and almost always you, well, can run something there (as you can edit php/other files right from web management ui).

Hordes of this (in Linux world).

reply
Same. I've been using it since 1996. Initially, we used it at an early ISP for DNS, SMTP, and POP3 for roughly 8K users, and it stuck with me.
reply
Free root for anyone for over 20 years too.
reply
Not sure why the snark but if people are running FreeBSD then they should be...basket weaving instead of using it? Yes, the correct solution is to patch and reboot but not everyone is in a place to jump and do that which is why a temp workaround, if possible, would be welcome
reply
I think good system should be prepared to do a reboot in a short notice. Even some long running jobs can have a pause mechanism.
reply
...as opposed to what, exactly? Linux is a 34 y.o. monolithic kernel in C, the BSDs are all forked from the same base (386BSD) of around the same age, XNU is 29 years old (and also heavily based on BSD code while also throwing in mach code) in C and other languages,...
reply
The 33 year old Windows NT kernel, duh.
reply
Why can't they? Upgrading and rebooting is kinda the standard response for most security issues. So I would expect something like Ansible's playbooks for this exact scenario. You might also have it setup as a staggered rollout.
reply
What prevents it?
reply