3 ms·
On the workstation part, it recommends QubesOS. Am I the only one who is skeptical about it? From what I saw superficially reading their source code, there ar
by kakwa_ 10y ago
On the workstation part, it recommends QubesOS.
Am I the only one who is skeptical about it?
From what I saw superficially reading their source code, there are some frightening stuff going on:
* tons of C code with nearly zero unit tests, same with the python code
* lots glue in form of bash or python scripts
* some not so beautiful stuff like:
- https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-init.d/qubes-firewall#L29 https://github.com/QubesOS/qubes-core-agent-linux/blob/maste... (kill -9 on a daemon...)
- https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-init.d/qubes-firewall#L18 https://github.com/QubesOS/qubes-core-agent-linux/blob/maste... (a daemon is a little bit more than an exe launched with '&'
- https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-init.d/qubes-core-appvm#L34 https://github.com/QubesOS/qubes-core-agent-linux/blob/maste... (changing a config file in an init script, humm, weird...)
- https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-init.d/qubes-core-appvm#L32 https://github.com/QubesOS/qubes-core-agent-linux/blob/maste... (starting a service inside the init of another service...)
- https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-init.d/qubes-qrexec-agent#L13 https://github.com/QubesOS/qubes-core-agent-linux/blob/maste... ("logging" with stderr redirection in a file)
And it's just the init scripts... I'm too lazy to take a look further inside the C or python stuff.
IMHO, as a proof of concept, it's interesting, as a finished, reliable and secure OS, it's frightening...
- mricon 10y agoIt's not really a recommendation. It's presented as one of the free software projects attempting to tackle workstation security. Another one is SubgraphOS.
- nickpsecurity 10y agoThat's not how I read it: "The only serious attempt at workstation security" "The Volvo of blah blah" Quite a slam to those of past and present that handed NSA or DOD pentesters their asses back to them. Maybe be more accurate if you said "a FOSS attempt at workstation security" minus Volvo part. Volvo probably goes to INTEGRITY-178 as SKPP cert requires more attack areas to be covered plus 2 years of pentesting for kernel. Genode Architecture is prime contender for FOSS far as foundations go. Next time a FOSS project claims to be designed securely just ask for a covert storage and timing channel analysis of any components that handle secrets. They'll either say "Huh? What's a covert channel analysis?" or "We don't really have anyone doing that as we're too understaffed or it doesn't really matter." ;)
- nickpsecurity 10y agoI slammed Joanna for its issues in the past. It's kind of a merger between features of Compartmented Mode Workstations and an insecure, virtualization platform. This author fails by thinking it's the only attempt at a secure workstation. There were many with market ignoring them mostly. It's why only a few remain. Demand-side problem. Anyway, the best way to do it is a microkernel or separation kernel that virtualized Linux with security-critical stuff running directly on the microkernel & communicating through protected IPC. That's the MILS/SKPP model whose first commercial releases were around 2005 or so with security kernels doing similar stuff in 90's. Closest thing to that in FOSS is GenodeOS: uses many proven components from CompSci like Genode, Nitpicker, Muen, and seL4. They're a small outfit. They need contributors to get it into Beta shape. Separation kernels & their platforms https://os.inf.tu-dresden.de/papers_ps/nizza.pdf https://os.inf.tu-dresden.de/papers_ps/nizza.pdf Note: CompSci stuff that explains how these things work really well without corporate marketing. :) This is similar to separation kernels below, GenodeOS and Sirrix's TrustedDesktop. http://www.ghs.com/products/safety_critical/integrity-do-178b.html http://www.ghs.com/products/safety_critical/integrity-do-178... Note: The design techniques listed here make for strong guarantees against apps screwing it up. Esp "hard currency." Worth copying by any FOSS project. http://www.lynx.com/pdf/LynxSecureDatasheetFinal.pdf http://www.lynx.com/pdf/LynxSecureDatasheetFinal.pdf Note: One with more features and risk to make app development easier. Nice visuals showing split between untrusted OS's & runtime partitions w/ careful comms. https://www.defcon.org/html/TEXT/8/db-8-Mythrander.ppt https://www.defcon.org/html/TEXT/8/db-8-Mythrander.ppt Note: Great presentation on CMW capabilities & risks. Several are on market but Argus is most mature & featured. Orange Book taught us to use CMW/OS features for medium-assurance, damage reduction with security kernels isolating those & individual tasks for high-security. Balance in everything. Argus runs on Red Hat Linux now. So, yes, there's plenty of them going back to 90's with a variety of security tradeoffs. Strongest ones use split app architecture with untrusted VM's for legacy stuff (or OS's) plus isolated runtimes on high-security kernels. Usually custom, slimmed-down stacks for filesystem and networking that isolate against OS-level attacks. A few, like GEMSOS (old) or Muen (recent), were implemented in safer languages to reduce error potential. Such features were in my recommendations to QubesOS mailing list, rejected entirely, and some later implemented as if it was their idea all along. Best to avoid it unless vanilla malware is the concern. ;)