Qubes code audit

[nokke]

@illuminati

I’d be happy to moderate and coordinate such a program with perhaps another volunteer.

I’m new here but if you’re happy to define what’s needed then I could take some of the load.

[GWeck]

I strongly support the idea of code auditing, especially as the number of sophisticated attacks against trustworthy open-source projects is increasing. Apart from the infamous xz-attack, which was averted at the last minute, there are now similar attacks reported on JavaScript development. While there is no guarantee that such attacks could always be detected in time, code auditing increases the probability of finding harmful injections into the code.

While I am very confident that the cautious approach of the Qubes team to including software in the project reduces the chances of such an attack significantly, any scheme helping to find possible malicious input will help to keep the current high quality of this system. This is especially important since just this quality may make Qubes a worthwhile target for such attacks.

[distopia]

@illuminati

I’m interested in improvements for backups, but I don’t think I could help out with that at the moment.

Sorry my initial question about backup improvement was too wide from this specific topic goal of auditing. I mixed up a little the different purposes of both topics.

Eventual backup tool improvement stays in the previously mentioned topic. To narrow it down to the goal of this one, could a security audit of the code involved in native backup be of interest for you ? And perhaps a good candidate for a pilot community audit session ?

A reason why I made the link was :

In previously mentioned incremental backup topic Tasket is talking about some potential flaws (security issues ?) with native backup tool (run in dom0).

@tasket

From a security perspective, Wyng also has advantages. Unlike qvm-backup it doesn’t parse any un-verified tar archives or other metadata in dom0 (qvm-backup creates archives with two tar layers, the outer layer is un-verified when its processed)– in an OS security model where even reading partition tables in dom0 is considered risky, this is significant.

Wyng also doesn’t hand complex archival tasks to untrusted VMs nor to dispVMs that mount untrusted volumes, which is possible attack surface for causing DoS or worse compromise (and tends to be slow).

To which Rustybird replies :

@rustybird

There’s no signing mechanism (@distopia), but there is a mechanism to defang the outer tar format layer of the Qubes OS backup file during restore:

Assuming that the backup file is being provided by a VM (i.e. it wasn’t manually copied into dom0!), restore.py will not deal with complex tar format data directly. Rather the VM has to convert it to the simpler qfile format (as used for inter-VM filecopy, or for receiving dom0 .rpm package updates) before streaming that to dom0, where the stream will be processed by qfile-dom0-unpacker instead of the tar utility.

Incremental backup possibilities - #34 by rustybird

There are maybe other components which have a higher priority, I remain interested in community auditing for any component.

[illuminati]

Full-Disclosure: For the sake of transparency, I go by the name @quantumpacket here and on GitHub (profile). This is just my tongue-in-cheek secondary account. Illuminati confirmed!

---

That being said, I’m really excited at all the interest thus far. Hopefully that interest only grows and more QubesOS users are ready to dive in and help out. The only way this program will be a success is if we can keep people engaged and make it such that anyone will feel comfortable to participate regardless of their level of technical background or expertise. I suspect a lot of people including myself will learn a lot about how QubesOS works on the inside as a result of this.

I’m going to do all I can to get this all setup with @nokke over the coming weeks, but we’re going to need a lot of feedback from you all in making sure any barriers for participants are addressed, and all logistics are sorted out before a pilot launch. So stay tuned!

---

@nokke

I’m new here but if you’re happy to define what’s needed then I could take some of the load.

@nokke Awesome, thanks for stepping up and volunteering! I’m working on a preliminary outline for how the program would be run and will reach out to you via DM to collaborate on it before we post it here for feedback.

---

@adw Could you create a new forum Category called Code Audit, that would show up on the left pane and add the names @quantumpacket and @nokke to it? Let’s make it temporarily private while we get things setup. The plan is to use the new category to organize each component audit and to have a central place for the program resources and discussion. Thank you!

[quantumpacket]

@distopia

There are maybe other components which have a higher priority, I remain interested in community auditing for any component.

Could you link me to the source for the backup code? We will be starting off with the core-* components as suggested by the QubesOS team. If it’s part of one of those components then the answer is yes.

I’ll be choosing a smaller component for the pilot launch and ramp up to larger ones as we get more community involvement. I’m afraid to bite off too much from the start and have engagement fizzle out due to people being overwhelmed.

[adw]

@illuminati

@adw Could you create a new forum Category called Code Audit, that would show up on the left pane and add the names @quantumpacket and @nokke to it? Let’s make it temporarily private while we get things setup. The plan is to use the new category to organize each component audit and to have a central place for the program resources and discussion. Thank you!

Better to ask @deeplow about setting up forum stuff.

[parulin]

From what I understood, the tools like qvm-... (ie: qvm-backup) come from qubes-core-admin-client, see:

QubesOS/qubes-core-admin-client/blob/main/qubesadmin/tools/qvm_backup.py

But I didn’t read that code, so not sure about it. I tried to understand qvm-device once, so it can be another option… I don’t know if it’s in the scope of this audit, but if we want to start with something rather simple, the qvm-... tools could be a good start? Like qvm-tags?

What are the requirements to participate? I mean, I can read some python or shell code but I have no real knowledge of how to write secure code. Am I able to take part in this audit?

[distopia]

Great, it’s a qubes-core-* =D

qubes-core-admin-client/qubesadmin/backup at main ·...

The biggest file, restore.py is a 2,1k loc

[quantumpacket]

@distopia

The biggest file, restore.py is a 2,1k loc

wow, that’s a big file! Seeing how large some of these files can be, I may have to break things up. Where depending on the size of the component we choose a selection of files, audit them, and note them as checked, and repeat the process again with additional files. I want the amount of code to be digestible by participants, so as not to create any burnout and thus disinterest.

---

@parulin

What are the requirements to participate? I mean, I can read some python or shell code but I have no real knowledge of how to write secure code. Am I able to take part in this audit?

Anyone can participate, but we will be laying down some rules of etiquette so as not to clutter up the forum. More info on that will be provided on the outline. We’ll probably setup a Matrix room for basic questions and discussion.

Keep in mind it’s not the place to learn a new language, one should be reading the official documentation for that. We will be providing links in a pinned Resources post where one can read about security for different languages and that would be the best place for you to learn from. Different people with different areas and levels of expertise will have eyes on the code, so don’t feel like you have to know everything. The goal is to put our collective minds together.

[nokke]

I did a quick analysis of loc for the core-* components and main filetypes, which may help breaking things up, matching people to components, choosing the right size to get started with, etc. Because I used file suffixes and the shell code generally doesn’t use them, they’re not included. I used file suffixes to count most languages; shell data comes from: find . -type f -exec sh -c "file {} | grep -q \"shell script\" && echo {}" \; | xargs wc -l

core-admin

• C:215
• py:52247
• Makefile:459
• xml:323
• shell:996

core-admin-addon-whonix

• py:127
• Makefile:12

core-admin-client

• py:36511
• Makefile:260
• xml:599
• shell:99

core-admin-linux

• py:2796
• Makefile:50
• shell:992

core-agent-linux

• C:1710
• py:2390
• Makefile:734
• xml:484
• shell:5502

core-libvirt

• Makefile:69
• shell:60

core-qrexec

• C:7744
• py:13866
• Makefile:324
• shell:185

core-qubesdb

• C:4590
• py:21
• Makefile:185
• shell:57

core-vchan-xen

• C:1706
• Makefile:39
• shell:31

[Fan]

This sounds like an awesome idea! Although I’m not sure how the less tech-savvy could participate very much.

If you or anyone else can think of how, then I’d be more than happy to contribute.

If nothing else, a good explanation behind each portion of the OS that’s being looked at can lead to a better overall understanding of Qubes. I’ve certainly enjoyed my deep-dives. I know way more about linux now than I did running Ubuntu back in the day.

There’s a lot in the documentation that is either quite vague or outdated. Hopefully this project could also lead to deeper documentation updates.