4 ms·

That E-Mail is from 2007... This is from 2013: https://youtu.be/OXS8ljif9b8?t=395 https://youtu.be/OXS8ljif9b8?t=395

by ben_bai 11y ago

nickpsecurity 11y ago
"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.
- tedunangst 11y ago
  The OpenBSD covert channel analysis team is understaffed at the moment.
  - nickpsecurity 11y ago
    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.
    - tedunangst 11y ago
      So go run EROS. Why aren't you already?
      - nickpsecurity 11y ago
        Nah, I'm just not running OpenBSD. Gotta stay where the innovation is at, both in productivity and security. ;)
        tedunangst 11y ago
        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.
        nickpsecurity 11y ago
        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. ;)
      - throwaway2048 11y ago
        but its so fun to blast out buzzwords

That E-Mail is from 2007... This is from 2013: https://youtu.be/OXS8ljif9b8?t=395 https://youtu.be/OXS8ljif9b8?t=395

by ben_bai 11y ago

That E-Mail is from 2007... This is from 2013: https://youtu.be/OXS8ljif9b8?t=395 https://youtu.be/OXS8ljif9b8?t=395

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

tedunangst 11y ago
The OpenBSD covert channel analysis team is understaffed at the moment.
- nickpsecurity 11y ago
  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.
  - tedunangst 11y ago
    So go run EROS. Why aren't you already?
    - nickpsecurity 11y ago
      Nah, I'm just not running OpenBSD. Gotta stay where the innovation is at, both in productivity and security. ;)
      - tedunangst 11y ago
        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.
        nickpsecurity 11y ago
        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. ;)
    - throwaway2048 11y ago
      but its so fun to blast out buzzwords