5 ms·

NICTA/UNSW have apparently started working on a QubesOS port https://my.cse.unsw.edu.au/thesis/thesis_topic_details.php?ID=3289 https://my.cse.unsw.edu.au/thes

by csirac2 11y ago

NICTA/UNSW have apparently started working on a QubesOS port https://my.cse.unsw.edu.au/thesis/thesis_topic_details.php?ID=3289 https://my.cse.unsw.edu.au/thesis/thesis_topic_details.php?I... http://sel4.systems/pipermail/devel/2015-March/000312.html http://sel4.systems/pipermail/devel/2015-March/000312.html

throwaway7767 11y ago
Huh, I'm surprised I'm seeing this first in a HN comment. I read qubes-devel with interest and have not noticed anything from these guys, but it sounds like a great project. I really hope it's something that turns into an actual maintained project instead of dying after the paper is out like so many security-focused research projects, but the lack of communication doesn't give me great hope.
- nickpsecurity 11y ago
  That's because Joanna is against it and will aggressively defend their platform choice. After our argument online [1], she posted this essay [2] comparing QubesOS to other things. She censored my piece-by-piece counter, too, lol. She did eventually do something with trusted path and mentioned QubesOS could be ported to different platforms. So, there's some progress... Honestly, it wasn't clear whether she really understood INFOSEC (esp TCB concept) based on her replies so I avoid QubesOS. [1] http://pastebin.com/5fnh8g2S http://pastebin.com/5fnh8g2S [2] http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-...
  - hga 11y ago
    I remember one good argument she made, a reductionist one that if the firmware on your Ethernet adapter can be hacked without recourse or relief from the OS (she gave a specific example), reducing the Xen part of TCB was not too relevant. It's worth noting that the seL4 people haven't tried to formally verify it on x86 (and there's no 64 bit port to date that I know of, outside of possibly the lowRISC GSoC effort which I should check up on), only ARMv6 and v7 (which, I'll grant, also has to do with academic efforts to verify ARM in general). If you're that serious, seL4 serious, there's a good argument you should eschew Intel and start with some of the less chaotic ARM systems (i.e. not so much kitchen sink ones from the mobile world like the Broadcom chips the Raspberry Pies use). I take her as trying something rather different, the pragmatic approach of getting the best security possible out of our existing infrastructure, hence the use of x86, Xen, Fedora, etc., based in part on her experience when figuratively putting on a black hat. She's discovered a lot of exploits, hasn't she? (lowRISC also includes an effort with tags to make our existing C/C++ infrastructure safer). And without the prospect of a "secure" web browser aside from perhaps Servo someday, maybe....
    - nickpsecurity 11y ago
      re firmware. It's true and orthogonal. Just as the DARPA project is doing, you use the best tech and method for each part of the job. The recommendations I gave her were for kernel up mainly for isolation. Drivers should be written robustly, synthesized, use trusted hardware, and/or mediate the hardware. re x86 vs ARM. It's true. Remember, though, that I didn't tell her to use seL4: just re-use work in L4 family projects like Nizza or OKL4 to get their security + performance benefits. The idea is you get a good start, make sure you can swap in/out components, and someone puts a verified one in place later. This is exactly the approach GenodeOS team took along with using many things I recommended in other post. Only gripe with them is they're doing too many things at once rather than focusing on getting at least one in best, production mode. That said, I agree with keeping off x86. I've recommended ARM, MIPS, SPARC, and RISC-V for future work. SPARC is nice due to open specs, no licensing past $99 trademark, and GPL hardware available. RISC-V people building all kinds of things. SPARC and MIPS have already been modified for enhanced security by academics several times over. So, SPARC (esp Gaisler), MIPS, and RISC-V are my recommendations in that order putting usability/extensibility over pricing. re pragmatic approach. Sure, I agree with that part. The resulting approach combined things top on the CVE list onto a platform she published exploits for and criticized in other posts. Gotta wonder how far its security would go. ;) She was a good bug-hunter, though, when she understood how something worked. Didn't seem to understand strong, security engineering so I predicted QubesOS would be good for vanilla malware w/ some containment of advanced attacks. Basically, a nice improvement on and replacement for Compartmented Mode Workstations's. The TCB size and implementation are just too complex for high security. re secure browsers. For full-featured experience, you'll need either virtualization or my old KVM-switch method. More research in the former has only made the latter look more trustworthy over time haha. Anyway, I referenced a number of more-secure browser architectures in the comment below. Enjoy seeing variations of The Right Thing in action. :) Now, if only mainstream would put effort into improving those instead of the monolithic ones. Chrome was at least an OP-inspired attempt. Due credit for them. https://news.ycombinator.com/item?id=9969961 https://news.ycombinator.com/item?id=9969961
      - hga 11y ago
        My complaint about browsers is less about architecture (I mean, when using multiple processes is a vast improvement of the state of the art on the ground...), than what I gather is the vast amount of work required to get today's standard web pages to render well. There are, what, 4 state of the art rendering engines? (Two Microsoft, which has lots of money to spend, Webkit (now Apple and Google forked??), and Firefox's.) And there's much, much more to the security story for browsers. Then again, this is not a topic I've looked closely at, maybe there's more hope than I think, and continuing financial losses might prompt more rigor, although I don't recall the worse ones being purely browser exploits.
  - dfc 11y ago
    What/Who is "@Ph.T." referring to in the linked discussion?
    - nickpsecurity 11y ago
      I'm not sure. Ph.T. apparently followed both the Schneier's blog discussions and QubesOS mailing list. We were discussing many methods of using separation kernels for desktops, security appliances, inline-media encryptors, VPN's, and more. Going through details for a year or two. At some point, Ph.T. saw all that and asked about it on the QubesOS mailing list only to get our claims and their location in a comment section dismissed. That prompted my reply to the mailing list and argument that followed. That there's 250,000+ people lurking there for good information was why I put much of my design info there instead of my own blog.
      - dfc 11y ago
        I enjoy reading your comments here at HN. Would you care to provide a link to your blog? I understand if you would like to keep the personas disconnected.
        nickpsecurity 11y ago
        Why thank you! :) Your profile was an amusing read, too, haha. I don't maintain a blog: post on high-profile one's like Schneier's instead to get good techniques out there to wide audience. Reference copies stay there due to host's integrity and good peer review with me keeping links to many. I've been pulling them into local copies gradually to turn into a web site which will be powered with medium assurance tech at a minimum (esp my blog/comment signature scheme). Practice what I preach & build on it sort of thing. For now, I email the .txt files with the links and what posts I've pulled to whoever is really interested. Send me an email at the address in my profile and I'll return a [substantial] subset of my designs/essays along with a sample framework for high security.
nickpsecurity 11y ago
Running on L4 family's work is one option I suggested to QubesOS team years ago. Nice to see someone trying. It will tricky with seL4 as they have embedded focus and QubesOS is a desktop OS. I'm sure the requirements, obstacles, and fixes will make for enlightening reading for anyone doing similar projects.

by csirac2 11y ago

throwaway7767 11y ago

Huh, I'm surprised I'm seeing this first in a HN comment. I read qubes-devel with interest and have not noticed anything from these guys, but it sounds like a great project. I really hope it's something that turns into an actual maintained project instead of dying after the paper is out like so many security-focused research projects, but the lack of communication doesn't give me great hope.

nickpsecurity 11y ago
That's because Joanna is against it and will aggressively defend their platform choice. After our argument online [1], she posted this essay [2] comparing QubesOS to other things. She censored my piece-by-piece counter, too, lol. She did eventually do something with trusted path and mentioned QubesOS could be ported to different platforms. So, there's some progress... Honestly, it wasn't clear whether she really understood INFOSEC (esp TCB concept) based on her replies so I avoid QubesOS. [1] http://pastebin.com/5fnh8g2S http://pastebin.com/5fnh8g2S [2] http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-...
- hga 11y ago
  I remember one good argument she made, a reductionist one that if the firmware on your Ethernet adapter can be hacked without recourse or relief from the OS (she gave a specific example), reducing the Xen part of TCB was not too relevant. It's worth noting that the seL4 people haven't tried to formally verify it on x86 (and there's no 64 bit port to date that I know of, outside of possibly the lowRISC GSoC effort which I should check up on), only ARMv6 and v7 (which, I'll grant, also has to do with academic efforts to verify ARM in general). If you're that serious, seL4 serious, there's a good argument you should eschew Intel and start with some of the less chaotic ARM systems (i.e. not so much kitchen sink ones from the mobile world like the Broadcom chips the Raspberry Pies use). I take her as trying something rather different, the pragmatic approach of getting the best security possible out of our existing infrastructure, hence the use of x86, Xen, Fedora, etc., based in part on her experience when figuratively putting on a black hat. She's discovered a lot of exploits, hasn't she? (lowRISC also includes an effort with tags to make our existing C/C++ infrastructure safer). And without the prospect of a "secure" web browser aside from perhaps Servo someday, maybe....
  - nickpsecurity 11y ago
    re firmware. It's true and orthogonal. Just as the DARPA project is doing, you use the best tech and method for each part of the job. The recommendations I gave her were for kernel up mainly for isolation. Drivers should be written robustly, synthesized, use trusted hardware, and/or mediate the hardware. re x86 vs ARM. It's true. Remember, though, that I didn't tell her to use seL4: just re-use work in L4 family projects like Nizza or OKL4 to get their security + performance benefits. The idea is you get a good start, make sure you can swap in/out components, and someone puts a verified one in place later. This is exactly the approach GenodeOS team took along with using many things I recommended in other post. Only gripe with them is they're doing too many things at once rather than focusing on getting at least one in best, production mode. That said, I agree with keeping off x86. I've recommended ARM, MIPS, SPARC, and RISC-V for future work. SPARC is nice due to open specs, no licensing past $99 trademark, and GPL hardware available. RISC-V people building all kinds of things. SPARC and MIPS have already been modified for enhanced security by academics several times over. So, SPARC (esp Gaisler), MIPS, and RISC-V are my recommendations in that order putting usability/extensibility over pricing. re pragmatic approach. Sure, I agree with that part. The resulting approach combined things top on the CVE list onto a platform she published exploits for and criticized in other posts. Gotta wonder how far its security would go. ;) She was a good bug-hunter, though, when she understood how something worked. Didn't seem to understand strong, security engineering so I predicted QubesOS would be good for vanilla malware w/ some containment of advanced attacks. Basically, a nice improvement on and replacement for Compartmented Mode Workstations's. The TCB size and implementation are just too complex for high security. re secure browsers. For full-featured experience, you'll need either virtualization or my old KVM-switch method. More research in the former has only made the latter look more trustworthy over time haha. Anyway, I referenced a number of more-secure browser architectures in the comment below. Enjoy seeing variations of The Right Thing in action. :) Now, if only mainstream would put effort into improving those instead of the monolithic ones. Chrome was at least an OP-inspired attempt. Due credit for them. https://news.ycombinator.com/item?id=9969961 https://news.ycombinator.com/item?id=9969961
    - hga 11y ago
      My complaint about browsers is less about architecture (I mean, when using multiple processes is a vast improvement of the state of the art on the ground...), than what I gather is the vast amount of work required to get today's standard web pages to render well. There are, what, 4 state of the art rendering engines? (Two Microsoft, which has lots of money to spend, Webkit (now Apple and Google forked??), and Firefox's.) And there's much, much more to the security story for browsers. Then again, this is not a topic I've looked closely at, maybe there's more hope than I think, and continuing financial losses might prompt more rigor, although I don't recall the worse ones being purely browser exploits.
- dfc 11y ago
  What/Who is "@Ph.T." referring to in the linked discussion?
  - nickpsecurity 11y ago
    I'm not sure. Ph.T. apparently followed both the Schneier's blog discussions and QubesOS mailing list. We were discussing many methods of using separation kernels for desktops, security appliances, inline-media encryptors, VPN's, and more. Going through details for a year or two. At some point, Ph.T. saw all that and asked about it on the QubesOS mailing list only to get our claims and their location in a comment section dismissed. That prompted my reply to the mailing list and argument that followed. That there's 250,000+ people lurking there for good information was why I put much of my design info there instead of my own blog.
    - dfc 11y ago
      I enjoy reading your comments here at HN. Would you care to provide a link to your blog? I understand if you would like to keep the personas disconnected.
      - nickpsecurity 11y ago
        Why thank you! :) Your profile was an amusing read, too, haha. I don't maintain a blog: post on high-profile one's like Schneier's instead to get good techniques out there to wide audience. Reference copies stay there due to host's integrity and good peer review with me keeping links to many. I've been pulling them into local copies gradually to turn into a web site which will be powered with medium assurance tech at a minimum (esp my blog/comment signature scheme). Practice what I preach & build on it sort of thing. For now, I email the .txt files with the links and what posts I've pulled to whoever is really interested. Send me an email at the address in my profile and I'll return a [substantial] subset of my designs/essays along with a sample framework for high security.

nickpsecurity 11y ago

Running on L4 family's work is one option I suggested to QubesOS team years ago. Nice to see someone trying. It will tricky with seL4 as they have embedded focus and QubesOS is a desktop OS. I'm sure the requirements, obstacles, and fixes will make for enlightening reading for anyone doing similar projects.