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
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.