4 ms·

> You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even stronge

> You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not) Security mitigations work best in combinations, the entire purpose is to make it as hard as possible to attack the system.. suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part, but I don't expect you'll deliver. > You started with OpenBSD's features, accepted the claims as fact. I stated the facts, because I'm aware of and closely followed their development, having tested them. I accepted no claims as "facts". You can easily verify everything I've said, OpenBSD is open source.. and shocking, they pioneered that too.. having created anoncvs. Not much left to reply to in your post, because you're just grasping at proverbial straws.

nickpsecurity 10y ago
"Security mitigation work best in combinations," Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses. "suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part" Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet. These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too. "and shocking, they pioneered that too.. having created anoncvs." Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961. It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode. Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one. OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.
- stsp 10y ago
  There's a lot of security research going on at lots of places in all sorts of ways and that's great. But most of it results in better theoretical understanding. It doesn't result in an OS that can be used on commodity hardware in a production context. Good luck running Firefox on top of a some research OS written in Modula 3.
  - nickpsecurity 10y ago
    I just gave that as an example to illustrate the point about those security measures. There's others in real OS's and products in production now plus more that existed decades into the past. And quite a few, including one I named, can handle Firefox. Good, wild guess though as untrustworthy browsers designed for untrustworthy UNIXen are hard. ;) Look up OP2 Web Browser or IBOS Illinois Browser Operating System next time if you want architectures designed for secure OS's. Chrome's security was a knockoff of a predecessor of one.

nickpsecurity 10y ago

"Security mitigation work best in combinations," Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses. "suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part" Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet. These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too. "and shocking, they pioneered that too.. having created anoncvs." Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961. It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode. Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one. OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.

stsp 10y ago
There's a lot of security research going on at lots of places in all sorts of ways and that's great. But most of it results in better theoretical understanding. It doesn't result in an OS that can be used on commodity hardware in a production context. Good luck running Firefox on top of a some research OS written in Modula 3.
- nickpsecurity 10y ago
  I just gave that as an example to illustrate the point about those security measures. There's others in real OS's and products in production now plus more that existed decades into the past. And quite a few, including one I named, can handle Firefox. Good, wild guess though as untrustworthy browsers designed for untrustworthy UNIXen are hard. ;) Look up OP2 Web Browser or IBOS Illinois Browser Operating System next time if you want architectures designed for secure OS's. Chrome's security was a knockoff of a predecessor of one.