161–170 of 170 posts
Earlier quoted context omitted.
Pretty sure you're familiar with their claims.
I'm not actually, because I'm damn sure I've never seen a piece of openbsd marketing in my life. All i know is that they're oriented around security and are notorious about rejecting patches.
Kind of weird for you to defend a product if you've never even been to their website.
Earlier quoted context omitted.
Well, that's where OpenBSD falls short, it lacks facilities to really enforce defense in depth - even NetBSD has some better features in this regard.
I don't think that's true? It runs most services as their own separate users, with pledge+unveil to limit what they can access even more. That's very much depth.
Earlier quoted context omitted.
Just as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge. [1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...
Difference is that capsicum is after the fact and mostly about file descriptors. You need to open them in advance and _then_ call capsicum. But it does nothing about syscalls. Capsicum is really nice if you plan ahead, but pledge/unveil is easy to drop into any existing code base.
> capsicum is after the fact
After the fact in what sense? The program enters capability mode before touching any arguments or doing I/O. You have to set things up before enter capability mode because you can't escape out of it afterwards.
> it does nothing about syscalls
It does quite a lot about syscalls, in that it blocks or limits most of them. As the man page says: "Access to system calls in capability mode is restricted: some system calls requiring global namespace access are unavailable, while others are constrained."
In capability mode, you can use specific syscalls that operate on file descriptors, which limits the program to the specific capabilities it has been granted, e.g. pdkill(2) which is like kill(2) except you can only signal processes for which you have a process descriptor.
Oh, hey , a local-user-to-root exploit on OpenBSD. Cool! Those are rare , but not unheard of , unless you're talking about Windows or Linux, where you don't hear much about this bug class, just since it's common-as-rainfall. Anyway... Does this mean OpenBSD is suddenly less interesting? Nope, it's still pretty much the best-understandable general-purpose OS, ready for your RiiR fork. So, still go for that! Burn a uni…
Now I've seen it all.
Earlier quoted context omitted.
> they are ... finding ... vulnerabilities ... that have not been worth the time and effort ... that's kinda the entire point
The point of the comment you are replying to is that it's also not worth the time and effort to use LLMs to find vulnerabilities, if "time and effort" can be measured with "money". If you factor in all the money spent on training, GPU data centers etc, it's not actually a financially efficient way to find bugs unless you profit from creating demand for LLMs . LLMs aren't cheaper than humans per unit work, yet. They'r…
well, they do? it's a win-win, you can't really criticise an AI lab for doing AI instead of straight up giving money to security researchers
> If you factor in all the money spent on training
why would I? it's not a cybersec-specific model
Earlier quoted context omitted.
The point of the comment you are replying to is that it's also not worth the time and effort to use LLMs to find vulnerabilities, if "time and effort" can be measured with "money". If you factor in all the money spent on training, GPU data centers etc, it's not actually a financially efficient way to find bugs unless you profit from creating demand for LLMs . LLMs aren't cheaper than humans per unit work, yet. They'r…
> it's not actually a financially efficient way ... unless you profit from creating demand for LLMs well, they do? it's a win-win, you can't really criticise an AI lab for doing AI instead of straight up giving money to security researchers > If you factor in all the money spent on training why would I? it's not a cybersec-specific model
Sure I can, if they - or you - pretend "the entire point" is about useful security work rather than expensive loss-leading marketing and demand creation.
We shouldn't look at this and think "wow AI is super useful for security". We should look and this and think "wow, there's a LOT of capital going into persuading us that AI is super useful for security".
THAT is "the entire point".
Earlier quoted context omitted.
I don't think that's true? It runs most services as their own separate users, with pledge+unveil to limit what they can access even more. That's very much depth.
It is true. The do surface level protections, but have nothing to really lock down a system. What do they provide that can restrict an attacker who managed to compromise a remote service that wasn't using pledge or unveil? On other OS's, you can set things like append only, limit files being readable by particular processes, whitelist paths or executables from where the system may execute, etc etc etc.
You can't opt out of the protections and then complain that there are no protections
> On other OS's, you can set things like append only,
https://man.openbsd.org/chflags.1 lists such a flag
> limit files being readable by particular processes,
That's trivial by setting group/world permissions on any unix-like.
> whitelist paths or executables from where the system may execute,
So, https://why-openbsd.rocks/fact/noexec/ ?
> etc etc etc.
Etc etc etc.
Earlier quoted context omitted.
Sidenote but... I read this on that link: dnsmasq: Codex Security independently identified vulnerable patterns corresponding to four of the six dnsmasq CVEs later fixed in 2.92rel2: CVE-2026-4890 (opens in a new window), CVE-2026-4891 (opens in a new window), CVE-2026-4892 (opens in a new window), and CVE-2026-517 dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that…
"dnsmasq has had so many freaking security holes in 2025 and 2026 that atm I decided to just remove that thing from all my machines." Would be nice if OpenWRT would stop including it by default
Earlier quoted context omitted.
> it's not actually a financially efficient way ... unless you profit from creating demand for LLMs well, they do? it's a win-win, you can't really criticise an AI lab for doing AI instead of straight up giving money to security researchers > If you factor in all the money spent on training why would I? it's not a cybersec-specific model
>you can't really criticise an AI lab for doing AI instead of straight up giving money to security researchers Sure I can, if they - or you - pretend "the entire point" is about useful security work rather than expensive loss-leading marketing and demand creation. We shouldn't look at this and think "wow AI is super useful for security". We should look and this and think "wow, there's a LOT of capital going into pers…
> We shouldn't look at this and think
you're gonna tell me what to think now?
Earlier quoted context omitted.
It is true. The do surface level protections, but have nothing to really lock down a system. What do they provide that can restrict an attacker who managed to compromise a remote service that wasn't using pledge or unveil? On other OS's, you can set things like append only, limit files being readable by particular processes, whitelist paths or executables from where the system may execute, etc etc etc.
> compromise a remote service that wasn't using pledge or unveil? You can't opt out of the protections and then complain that there are no protections > On other OS's, you can set things like append only, https://man.openbsd.org/chflags.1 lists such a flag > limit files being readable by particular processes, That's trivial by setting group/world permissions on any unix-like. > whitelist paths or executables from whe…
Sometimes you don't have a choice in running software that doesn't use the 'protections' an obscure OS offers. If someone wants to run Oracle, pledge and unveil is irrelivant, as where other security solutions can still protect Oracle without requiring opt-in, and to a far greater extent.
> https://man.openbsd.org/chflags.1 lists such a flag
It's too blunt, it's an all or nothing approach. You have no way to say process A can append only, but privileged process b should have no write access at all.
> That's trivial by setting group/world permissions on any unix-like.
Only in the bluntest of terms. There is no way to allow, say, a webserverto have read access to a file while not allowing a cat processes, spawned as a subprocess of that webserver process, to not have access.
> So, https://why-openbsd.rocks/fact/noexec/ ?
No, not even close. I mean allowing user a to run /bin/ls to execute while not having access to execute /bin/rm, and at the same time allowing user b to execute both, and user c to run /bin/rm but not /bin/ls
> Etc etc etc.
No, not really, since you didn't make any point that were not based on misunderstandings.