Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD 7.9

openbsd.org

Post reply on HN
Print view View original

261–270 of 314 posts

Re: OpenBSD 7.9

#261

Post by keyle »

SanjayMehta wrote: post #39
nelsonic wrote: post #14

Earlier quoted context omitted.

We use OpenBSD for our VPSes on Hetzner, bare metal (for security focussed clients) and older (but still good) hardware in our Home Lab. OpenBSD is excellent on older (no longer supported by Cupertino) Apple hardware. We have an Intel Mac Mini Cluster with near-perfect uptime. If you need to run any kind of server (Web, Mail, DNS, NFS, Database) where you need stability & security, look no further. Some learning curv…

What's the situation with Broadcom wifi on your intel macs? We've run into instability issues with the newer Linux kernels (starting with 6.x, I think) and have had to stop upgrading.

I've just setup a new ThinkPad with openbsd. You just need to put the firmware needed on a usb stick, mount it and run one command, fw_update -p ./ It wasn't hard.

Re: OpenBSD 7.9

#262

Post by anthk »

infinet wrote: post #172
nelsonic wrote: post #11

With all the security issues constantly being uncovered in other Operating Systems - which will only accelerate with Ai - it’s time everyone considers OpenBSD. Their decades-long security-focus is second to none. We have fully converted from Ubuntu/Debian to OpenBSD. No looking back.

I tried OpenBSD recently and found it behaves very differently from other OS. The same code works on Linux/FreeBSD/Windows but has poor multi thread performance on OpenBSD, async socket stopped working after sending at high speed for few seconds. I am not saying there is anything wrong in OpenBSD, it is just different.

        doas sysctl hw.smt=1

Re: OpenBSD 7.9

#263

Post by creatonez »

somat wrote: post #256

"Introduced a mechanism to manage CPU cores with different speeds in the scheduler. The sysctl(8) variable "hw.blockcpu" takes a sequence of 4 letters: S (for SMT), P (regular performance CPU), E (efficient CPU, generally 80% to 50% as fast), and L (lethargic CPU) which are even slower. Set this to select CPUs to kick out of the scheduler (SL by default). Currently works on amd64 and arm64." I have to admit I am not…

> And even for background tasks shouldn't it be better to have them complete faster for less power

Race to idle is only clearly beneficial for tasks that have a clear start and end. If a background task is sustained, responds to unpredictable events, or does small amounts of work and wakes frequently, the CPU's boost logic won't solve your energy usage problem.

> To say nothing about what if they have different features. what happens when a process that wants to use cpu feature X(avx512?) gets scheduled on a cpu without X

This idea has been proposed in the past, but isn't actually used on x86-64 or ARM. E-cores have the same instruction set as P-cores, so there's no risk of running into an invalid CPU instruction.

Truly heterogeneous instruction sets may come back in the future, though. So be on your toes.

Re: OpenBSD 7.9

#264

Post by anthk »

JCattheATM wrote: post #259
binkHN wrote: post #248

Earlier quoted context omitted.

> OpenBSD focuses on auditing. This is partially true; there are numerous other things that are done for mitigation outside of this.

> there are numerous other things that are done for mitigation outside of this. Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD cou…

Namespaces are a joke under Linux compared ot 9front. The last exploits under bubblewrap ran the same. OpenBSD has OpenSSH pledge'd and unveil'ed.

Re: OpenBSD 7.9

#265

Post by wahern »

bombcar wrote: post #184
nelsonic wrote: post #145

Earlier quoted context omitted.

You are correct; OpenBSD is secure by default. And it's not subjective at all. The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-) Remote (exploitable) holes are the ones we all care about.

The key (and not saying it's bad, mind you) is that the default install has very few services installed, let alone running or open. So even if Debian and OpenBSD ship the exact same web server, but Debian has it defaulted installed and on, but OpenBSD does not, then a remote exploit won't count against OpenBSD.

All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.

How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.

Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.

Re: OpenBSD 7.9

#266

Post by wahern »

gjm11 wrote: post #87
866-RON-0-FEZ wrote: post #36

Earlier quoted context omitted.

Your "evidence" for him to reconsider is a sandbox "bypass" that requires you to be root to set up the environment? For my next trick I will demonstrate how to break into my own house to open the blinds by using my keys. Security researcher theatrics will never not be funny.

Maybe I'm misunderstanding the video, but it looks to me as if the situation is: You are root inside a sandbox . As root-in-the-sandbox, you create a symlink and this gives you the ability to escape the sandbox. (Whether this is interesting or not depends on whether anyone actually tries to use the sandbox facility in such a way as to give root-in-the-sandbox privileges to untrusted people or code. I don't know enoug…

unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.

The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.

Re: OpenBSD 7.9

#267

Post by JCattheATM »

anthk wrote: post #264
JCattheATM wrote: post #259

Earlier quoted context omitted.

> there are numerous other things that are done for mitigation outside of this. Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD cou…

Namespaces are a joke under Linux compared ot 9front. The last exploits under bubblewrap ran the same. OpenBSD has OpenSSH pledge'd and unveil'ed.

Don't make the perfect be the enemy of the good. Just because they didn't stop escape via dirtyfrag doesn't make them useless let alone a joke. pledge and unveil are nice, but exactly how effective do you expect them to be against an ssh/sftp server? Maybe you have ssh configured so it can't manipulate user and/or system files, but that isn't typically common usage.

Re: OpenBSD 7.9

#268

Post by thomashabets2 »

tete wrote: post #232
maxall4 wrote: post #90

Earlier quoted context omitted.

Is OpenBSD actually more secure than Linux? I have not been able to find any data to support this—only some vague opinions.

Given from what Anthropic says with Mythos: Yes.

I pointed plain old gpt 5.5 at openbsd and found plenty of bugs.

Sent patches for two just in "find".

Openbsd, like all other projects, needs a large scale LLM powered bug squash effort.

My recent experience: https://blog.habets.se/2026/05/Everything-in-C-is-undefined-...

Re: OpenBSD 7.9

#269

Post by salvesefu »

2b3a51 wrote: post #89
skydhash wrote: post #70

Earlier quoted context omitted.

Not GP, but I mostly use: Firefox; Emacs; MPV; Keepass; calibre; xfe; mupdf;... Then a bunch of cli tools. There's a lot in base, so cli are mostly extra utilities like cmus, git, tig, ncdu,...

I would imagine that a lot of people who use OpenBSD on their laptops/desktops run a lean installation with one of the window managers in base (an ancient fvwm version, cwm which I find very nice and twm). You can however have a full-fat desktop environment with xfce4 or gnome and applications like libreoffice, gimp, inkscape, audacity and so on if you wish. I've never tried KDE on top of OpenBSD base but I gather pa…

i wonder how gnome will be supported in the future on systems without systemd. heres a thread of someone beginning the process of replacing systemd with gnu shepherd: https://discourse.gnome.org/t/accompanying-non-systemd-distr...

Re: OpenBSD 7.9

#270

Post by elcritch »

pjmlp wrote: post #252
nelsonic wrote: post #11

With all the security issues constantly being uncovered in other Operating Systems - which will only accelerate with Ai - it’s time everyone considers OpenBSD. Their decades-long security-focus is second to none. We have fully converted from Ubuntu/Debian to OpenBSD. No looking back.

Unfortunately the hardware support isn't there for many systems. If I had to pick a BSD, it would be FreeBSD anyway.

Ugh FreeBSD is so much nicer than modern Linux. It's hard not to love.
Post reply on HN