https://news.ycombinator.com/item?id=38579913
I think? this is the same work, just now merged into the kernel?
> Security researchers have expressed doubt about how useful this check is at preventing compromises.
Doesn't cite the HN thread, but two other cases.
> I think? this is the same work, just now merged into the kernel?
That is my understanding, yes. From the article:
> In December, De Raadt sent a patch to the OpenBSD mailing list expanding OpenBSD's restrictions on the locations from which a process can make system calls. ... Now that patch has been merged, finishing a process which De Raadt said has taken five years.
> Only two remote holes in the default install, in a heck of a long time!
I'm assuming not, but I could always be mistaken.
this is on top of a lot of very careful programming and interesting security research, and this post isn't meant to take anything away from the OpenBSD devs.
Probably this issue has been hashed out many times over the decades, but arguably the security gain isn't a fortunate or incidental benefit of minimizing default enabled services, nor a cheat like weighted dice, it's a very real benefit resulting from an effective, intentional technique. Maybe other OSes should do the same, and then everyone would have that benefit.
The other OSes have other priorities, and that's fine. Embrace that. Yes, most users (and developers) don't want to deal with the compatibility issues. But when you say OpenBSD has few default security holes because they have few default services, that's a complement.
Also, doesn't SEL4 have widespread, practical application? IIRC as the microkernal (maybe under Minix?) on the baseband hardware on cell phones? Maybe I'm confusing it with something else.
As an example, CompCERT is a formally verified C compiler, and it's had a couple bugs as a result of their specification of the underlying hardware being wrong.
Part of why it is hard to take its reputation as as security focused OS seriously.
Failed experiments are also a good part of research.