4 ms·

Does it matter what he has to say though? The thing isn't even out yet. His speculations are about as good as anyone's at this point and, in the end, it really

by lhorie 17y ago

Does it matter what he has to say though? The thing isn't even out yet. His speculations are about as good as anyone's at this point and, in the end, it really is up to you to decide what to call bs on, whether it came from a celebrity's mouth or not.

tptacek 17y ago
Things I care about here: (1) The "virus-free OS" meme, which is pernicious and displaces reasonable thinking about system security, which is something that everyone --- Apple, Linux, Microsoft, and Google included --- are working hard on. (2) The guru phenomenon, where people embed themselves into the industry consciousness and become fonts for random meaningless sound bites. Probably good to call me out for obsessing about it, though I'll note that I feel comfortable babbling about it on Hacker News because I "know" you people, and would be less comfortable talking to a reporter about it.
- Retric 17y ago
  What bothers me about this discussion is the assumption that crappy software people are used to is the only type it's possible to build. You can write software that deals with reasonable levels of memory corruption when it's operating. As in this will survive if no more than X bits are flipped per second in either the source code or RAM. Yes, it's slow and expensive to create and operate, but it is also possible. Yet his argument is based on the assumption that you need a virus scanner for some reason. I know it's hard and expensive to create clean systems, but that's a long way from impossible. PS: What I love about Hacker News is talking with people who understand some things and a far deeper level than I do, and are also willing to listen to a reasonable argument.
  - stcredzero 17y ago
    What bothers me about this discussion is the assumption that crappy software people are used to is the only type it's possible to build. A capability system would be a lot harder to completely corrupt. Sandboxing can limit damage to manageable compartments, and enable the system to roll back without user intervention. I think you could make an OS two orders of magnitude harder than current commonly used systems. It will never be complete mathematically provable security. Just make it so hard to do, that the cost increases enough to change the fundamental economics, so that only very high value targets will ever get that degree of attention. (Which means that the cost has to be much higher than someone's credit card number.)
    - tptacek 17y ago
      Bernstein disagrees with you, in his analyis of 10 years of qmail security. Worth reading. The problem with sandboxing is the misalignment of effort between attacker and defender. Sandboxing and capabilities are a huge pain in the ass for the defender, who have to construct and deploy applications with perfectly configured security controls. They're just an obstacle course for attackers.
      - Retric 17y ago
        qmail is a program written in C which runs on UNIX. Trying to secure that is a near impossible task. Building a secure system would basically need to start from scratch with a micro kernel which supported a sandboxed OS written in an interpreted language. Even then drivers and HW would need to be treated with the utmost care. Granted, actually building such a system would be horribly expensive and probably take the better part of a decade, but it's still possible.
        tptacek 17y ago
        It's easy to specify secure systems that don't do anything in the real world.
        Retric 17y ago
        I completely agree.
        stcredzero 17y ago
        need to start from scratch with a micro kernel which supported a sandboxed OS written in an interpreted language Didn't Microsoft already do this with Singularity? Granted, actually building such a system would be horribly expensive and probably take the better part of a decade, but it's still possible I don't think it would be so horribly expensive. The Lisp machine software was written by a team of 8 or so. The effort for an OS is probably commensurate with BeOS. That's expensive, but not horribly so. Retarget a C compiler for your VM bytecodes, or better yet, just have everything run in an NaCl sandbox. Instead of bytecodes, have your virtual ISA be pseudo x86 or ARM instructions. Then port a lot of GNU code over.

by lhorie 17y ago

tptacek 17y ago

Things I care about here: (1) The "virus-free OS" meme, which is pernicious and displaces reasonable thinking about system security, which is something that everyone --- Apple, Linux, Microsoft, and Google included --- are working hard on. (2) The guru phenomenon, where people embed themselves into the industry consciousness and become fonts for random meaningless sound bites. Probably good to call me out for obsessing about it, though I'll note that I feel comfortable babbling about it on Hacker News because I "know" you people, and would be less comfortable talking to a reporter about it.

Retric 17y ago
What bothers me about this discussion is the assumption that crappy software people are used to is the only type it's possible to build. You can write software that deals with reasonable levels of memory corruption when it's operating. As in this will survive if no more than X bits are flipped per second in either the source code or RAM. Yes, it's slow and expensive to create and operate, but it is also possible. Yet his argument is based on the assumption that you need a virus scanner for some reason. I know it's hard and expensive to create clean systems, but that's a long way from impossible. PS: What I love about Hacker News is talking with people who understand some things and a far deeper level than I do, and are also willing to listen to a reasonable argument.
- stcredzero 17y ago
  What bothers me about this discussion is the assumption that crappy software people are used to is the only type it's possible to build. A capability system would be a lot harder to completely corrupt. Sandboxing can limit damage to manageable compartments, and enable the system to roll back without user intervention. I think you could make an OS two orders of magnitude harder than current commonly used systems. It will never be complete mathematically provable security. Just make it so hard to do, that the cost increases enough to change the fundamental economics, so that only very high value targets will ever get that degree of attention. (Which means that the cost has to be much higher than someone's credit card number.)
  - tptacek 17y ago
    Bernstein disagrees with you, in his analyis of 10 years of qmail security. Worth reading. The problem with sandboxing is the misalignment of effort between attacker and defender. Sandboxing and capabilities are a huge pain in the ass for the defender, who have to construct and deploy applications with perfectly configured security controls. They're just an obstacle course for attackers.
    - Retric 17y ago
      qmail is a program written in C which runs on UNIX. Trying to secure that is a near impossible task. Building a secure system would basically need to start from scratch with a micro kernel which supported a sandboxed OS written in an interpreted language. Even then drivers and HW would need to be treated with the utmost care. Granted, actually building such a system would be horribly expensive and probably take the better part of a decade, but it's still possible.
      - tptacek 17y ago
        It's easy to specify secure systems that don't do anything in the real world.
        Retric 17y ago
        I completely agree.
      - stcredzero 17y ago
        need to start from scratch with a micro kernel which supported a sandboxed OS written in an interpreted language Didn't Microsoft already do this with Singularity? Granted, actually building such a system would be horribly expensive and probably take the better part of a decade, but it's still possible I don't think it would be so horribly expensive. The Lisp machine software was written by a team of 8 or so. The effort for an OS is probably commensurate with BeOS. That's expensive, but not horribly so. Retarget a C compiler for your VM bytecodes, or better yet, just have everything run in an NaCl sandbox. Instead of bytecodes, have your virtual ISA be pseudo x86 or ARM instructions. Then port a lot of GNU code over.