
Security challenges for the Qubes build process - kkl
http://blog.invisiblethings.org/2016/05/30/build-security.html
======
wongarsu
Their build process sounds similar to Bitcoin Core's release process.

Bitcoin downloads dependencies, checks them against their preconfigured hashes
and then builds the different versions (Windows, Linux, Mac) in different VMs.
The build is deterministic and thus produce the exact same files for
everybody. Everyone signs the files they produced and uploads the signature.
If all the signatures are valid for the same file you can be reasonably sure
that the build process wasn't tampered with.

Getting deterministic builds even for a project like Bitcoin Core with few
dependencies was hard. On the scale of Qubes this would be a monumental task.
But maybe Debian's initative for reproducible builds makes this easier in the
future.

~~~
j_s
To what degree are the Bitcoin build VMs reproducible vs. giant binary blobs?

~~~
wongarsu
The build VMs are predefined Ubuntu LTS releases. The build system that sets
everything up is a bunch of barely documented scripts.

------
gaius
Rutkowska is surely doing some of the most interesting research in this field.

~~~
CiPHPerCoder
Rutkowska is among the _crème de la crème_ of computer security researchers.
That she's dedicating her time towards a project like Qubes is sorely under-
appreciated by the public today, but is certainly something that inspires me
to believe that, given enough time, _defenders can win_.

~~~
nickpsecurity
I'll give her credit for putting the time in more than most. Even I'm guilty
on that one as my brain-damaged ass could be cloning UNIX apps in Rust or
SPARK or something with MAC or Capsicum policies. My research is important but
most of us doing such things don't do enough OSS coding.

------
nickpsecurity
Anyone interesting in securing repo's or build systems should start with
Wheeler's landmark collection on the topic:

[http://www.dwheeler.com/essays/scm-
security.html](http://www.dwheeler.com/essays/scm-security.html)

Has basics in English, CompSci work, high-assurance considerations, and some
example projects. A bright, security researcher that's very familiar with
DVCS's should redo this in light of them with similar recommendations. More
like a team of bright researchers but it needs to be done. I'm interested in
any papers people already have on this that have similarly-thorough treatment
of threat model and proposed mitigations.

Once you know builds, you might want to address subversion, design,
implementations, covert channels, and other things if you're trying to stop
Five Eyes, Russia, or China. That requires "high-assurance" security
methods... when it's even possible... Got a small list here to get people
started on how deep the issue goes just at high-level and subversion aspects:

[https://news.ycombinator.com/item?id=10478742](https://news.ycombinator.com/item?id=10478742)

------
d33
I heard that Qubes is riddled with undocumented scripts that have no automated
tests for them. Does anybody know how true is that?

~~~
kakwa_
Just in case, I'm reposting my message from
[https://news.ycombinator.com/item?id=11652940](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...](https://github.com/QubesOS/qubes-core-agent-
linux/blob/master/vm-init.d/qubes-firewall#L29) (kill -9 on a daemon...)

\- [https://github.com/QubesOS/qubes-core-agent-
linux/blob/maste...](https://github.com/QubesOS/qubes-core-agent-
linux/blob/master/vm-init.d/qubes-firewall#L18) (a daemon is a little bit more
than an exe launched with '&'

\- [https://github.com/QubesOS/qubes-core-agent-
linux/blob/maste...](https://github.com/QubesOS/qubes-core-agent-
linux/blob/master/vm-init.d/qubes-core-appvm#L34) (changing a config file in
an init script, humm, weird...)

\- [https://github.com/QubesOS/qubes-core-agent-
linux/blob/maste...](https://github.com/QubesOS/qubes-core-agent-
linux/blob/master/vm-init.d/qubes-core-appvm#L32) (starting a service inside
the init of another service...)

\- [https://github.com/QubesOS/qubes-core-agent-
linux/blob/maste...](https://github.com/QubesOS/qubes-core-agent-
linux/blob/master/vm-init.d/qubes-qrexec-agent#L13) ("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...

~~~
nickpsecurity
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.

