Yes, people have repeated that line since 2008. Readers certainly saw the timestamp. It was main Q&A and search result, though. Hence asking for modern post.
"This is from 2013"
And that's a start. Appreciate the link. I don't see many of his interviews but that was the first one I saw him admit to being behind. Good they're changing their attitude a bit.
The expected and somewhat disappointing part is when he has no answer to what can be done to raise the bar past a few exploit mitigations. There's something like four decades of work (and worked examples) showing how to increase assurance of security in hardware, software, and systems. Especially in capability, microkernels, static analysis, covert channel analysis, and so on. He could... idk... apply some of that instead of mock and ignore it like most mainstream does. FreeBSD is ahead here with SEBSD and Capsicum work.
One project did port OpenBSD to L4 kernel to isolate it in a protection domain. The idea, as in Nizza Security Architecture, is to be able to split system into legacy, untrusted stuff in VM and trusted, highly-assured components running directly on microkernel. A proven model that would benefit OpenBSD by dramatically reducing attack surface. This is done in embedded space (eg INTEGRITY, PikeOS Hypervisor) for up to 8 ISA's each for those wondering about portability.
Just one of dozens of techs to draw on to increase assurance. Will be interesting to see if they draw on any of this or get left behind [again] by those that do.
Both EROS and Genode managed to do a lot of what I mentioned with less staff & time. Plus, with solid architecture that above components can leverage without doing all the highly assured stuff over and over again: what I call security ROI. Your huge TCB, drivers probably in kernel, and language-related issues are where I predicted most of the trouble would come from. (Did it?) Something like Nizza Security Architecture would benefit you along with interface checks you're already good at and a better language that translates to C with checks automatically inserted.
Far as covert channels, Google Kemmerer's Shared Resource Matrix for a method that worked for amateurs and pro's alike on a budget. Any person handling a subsystem can apply it. Even using it on function call level can tell you a lot. If understaffed, just use it on any component handling secrets for storage and timing channels. Best bang for buck.
Ok, to be more serious for a bit, a goal of the OpenBSD project is to produce a Unix like operating system. To the extent "innovation" is "don't be Unix" it's somewhat counter to project goals.
Well, there we go. That's unfortunate, but understandable. However, it still allows you to build on decades of work in security engineering (incl old secure UNIX's). The easiest route at this point is putting OpenBSD API on top of a microkernel, pulling security-critical functionality out of main system onto microkernel, and bulletproofing your middleware for these. Additionally, writing the code in a way that lets tools such as Astree Analyzer work on as much of it as possible will knock out many bugs. Compiler tools that automatically transform kernel or user-mode code to make it safer might help. Softbound + CETS comes to mind.
Much to draw on or improve while remaining a UNIX. The microkernel + user-mode virtualization approach has already been done in academia and commercial products. So, it could be done here. Will they? Another matter entirely. I doubt it.
Truth be told, though, I voted for the Xen Dom0 to use OpenBSD because 0-days would be its main concern. And we know which team is the best at removing them from a UNIX codebase. ;)
It's fun to do what the sheep or crowds are doing. That's Windows, Mac, BSD, or UNIX at any given time. Throw in C/C++ everywhere, browsers, Flash, HTTP as universal transport, language runtimes too bloated to understand, the Cloud... the more vulnerabilities and maintenance horrors, the more they'll like you and the more fun you'll have with them.
Our security needs to improve dramatically. Some ways are proven to work, some are proven not to. Pushing the second category is extremely fun, you might get famous in Silicon Valley companies, maybe invited to DEFCON, and everyone will make excuses for its problems later. Lots of buzzwords there, I agree: can't even mentally track all of them. Then there's a tinier group pushing methods that work because they're necessary, even if not all fun. Staying with that group on principle if not profit.
Comments
"That E-Mail is from 2007..."
Yes, people have repeated that line since 2008. Readers certainly saw the timestamp. It was main Q&A and search result, though. Hence asking for modern post.
"This is from 2013"
And that's a start. Appreciate the link. I don't see many of his interviews but that was the first one I saw him admit to being behind. Good they're changing their attitude a bit.
The expected and somewhat disappointing part is when he has no answer to what can be done to raise the bar past a few exploit mitigations. There's something like four decades of work (and worked examples) showing how to increase assurance of security in hardware, software, and systems. Especially in capability, microkernels, static analysis, covert channel analysis, and so on. He could... idk... apply some of that instead of mock and ignore it like most mainstream does. FreeBSD is ahead here with SEBSD and Capsicum work.
One project did port OpenBSD to L4 kernel to isolate it in a protection domain. The idea, as in Nizza Security Architecture, is to be able to split system into legacy, untrusted stuff in VM and trusted, highly-assured components running directly on microkernel. A proven model that would benefit OpenBSD by dramatically reducing attack surface. This is done in embedded space (eg INTEGRITY, PikeOS Hypervisor) for up to 8 ISA's each for those wondering about portability.
Just one of dozens of techs to draw on to increase assurance. Will be interesting to see if they draw on any of this or get left behind [again] by those that do.
The OpenBSD covert channel analysis team is understaffed at the moment.
Both EROS and Genode managed to do a lot of what I mentioned with less staff & time. Plus, with solid architecture that above components can leverage without doing all the highly assured stuff over and over again: what I call security ROI. Your huge TCB, drivers probably in kernel, and language-related issues are where I predicted most of the trouble would come from. (Did it?) Something like Nizza Security Architecture would benefit you along with interface checks you're already good at and a better language that translates to C with checks automatically inserted.
Far as covert channels, Google Kemmerer's Shared Resource Matrix for a method that worked for amateurs and pro's alike on a budget. Any person handling a subsystem can apply it. Even using it on function call level can tell you a lot. If understaffed, just use it on any component handling secrets for storage and timing channels. Best bang for buck.
So go run EROS. Why aren't you already?
Nah, I'm just not running OpenBSD. Gotta stay where the innovation is at, both in productivity and security. ;)
Ok, to be more serious for a bit, a goal of the OpenBSD project is to produce a Unix like operating system. To the extent "innovation" is "don't be Unix" it's somewhat counter to project goals.
Well, there we go. That's unfortunate, but understandable. However, it still allows you to build on decades of work in security engineering (incl old secure UNIX's). The easiest route at this point is putting OpenBSD API on top of a microkernel, pulling security-critical functionality out of main system onto microkernel, and bulletproofing your middleware for these. Additionally, writing the code in a way that lets tools such as Astree Analyzer work on as much of it as possible will knock out many bugs. Compiler tools that automatically transform kernel or user-mode code to make it safer might help. Softbound + CETS comes to mind.
Much to draw on or improve while remaining a UNIX. The microkernel + user-mode virtualization approach has already been done in academia and commercial products. So, it could be done here. Will they? Another matter entirely. I doubt it.
Truth be told, though, I voted for the Xen Dom0 to use OpenBSD because 0-days would be its main concern. And we know which team is the best at removing them from a UNIX codebase. ;)
but its so fun to blast out buzzwords
It's fun to do what the sheep or crowds are doing. That's Windows, Mac, BSD, or UNIX at any given time. Throw in C/C++ everywhere, browsers, Flash, HTTP as universal transport, language runtimes too bloated to understand, the Cloud... the more vulnerabilities and maintenance horrors, the more they'll like you and the more fun you'll have with them.
Our security needs to improve dramatically. Some ways are proven to work, some are proven not to. Pushing the second category is extremely fun, you might get famous in Silicon Valley companies, maybe invited to DEFCON, and everyone will make excuses for its problems later. Lots of buzzwords there, I agree: can't even mentally track all of them. Then there's a tinier group pushing methods that work because they're necessary, even if not all fun. Staying with that group on principle if not profit.