zlacker

[return to "Security challenges for the Qubes build process"]
1. d33+93[view] [source] 2016-05-30 13:44:01
>>kkl+(OP)
I heard that Qubes is riddled with undocumented scripts that have no automated tests for them. Does anybody know how true is that?
◧◩
2. kakwa_+in[view] [source] 2016-05-30 18:53:43
>>d33+93
Just in case, I'm reposting my message from https://news.ycombinator.com/item?id=11652940

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/maste... (kill -9 on a daemon...)

- 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/maste... (changing a config file in an init script, humm, weird...)

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

◧◩◪
3. nickps+3H[view] [source] 2016-05-30 23:21:20
>>kakwa_+in
It's hall-marks of a low-assurance, software project hacked together to get it working with OSS components. There could be strong review in scripts or C code as the team are talented coders and breakers from what I've read. The minimum in high-assurance security... even medium-assurance... was that every feature was tested for proper behavior during successful execution and failures. Plus, a description of why it's there that traces to a functional or security requirements. That's so evaluators can spot unnecessary code that might be a backdoor or just dead code.

Python for those scripts is questionable, too, as it's too complex to analyze with known principles of security engineering. It should be a 3GL that maps well to hardware with easy way to spot code-level flaws or automated them out (esp static analysis). You can abstract it, even macro it, so long as final code can be subjected to whatever eyeballs or tools are out there with ease. Non-security-critical stuff can be written in something like Python, though.

[go to top]