Qubes code audit

I’d like a community driven program where the QubesOS team selects a QubesOS repository/component of their choosing, and for that week or month that repository/component is highlighted on the forum/website/Github/etc for a community audit. A thread can be made to discuss any findings of concern, clarifications on what code is doing for the less savvy, better ways of doing things, code cleanup, etc.

This way we can get a focused look on each area of concern instead of multiple eyes all over the place. We would essentially be doing a group audit, component by component over time.

8 Likes

now that qubes is getting more popular and after xz utils backdoor, i think its important to make bump this on the priority list :slight_smile:

1 Like

Great idea !

Found the code complexity, surface, number of components kind of overwhelming when landing on Qubes planet - still today btw. And I am quite tech-savvy but Qubes is definitely a great piece of engineering. This idea to spotlight different components regularly could leverage momentum for people eager to dig in.

Are you close to launch / animate such program :slight_smile: ?

Would be in, for real, reading and writing not-too-complex C / C++

3 Likes

I’d be happy to moderate and coordinate such a program with perhaps another volunteer. But I think it would be best to first ask @adw as the Community Manager if such a community program would be endorsed by the Qubes team.

If so, I can write up a draft on how it would be organized, and we could do a pilot run on a small component/repository for 1-month and see how it goes?

5 Likes

I’ll ask the team about this and let you know what I hear. :slight_smile:

3 Likes

The team thinks this is a good idea! One specific recommendation is to start with some of the core-* components. There are also app-* components (like u2f and gpg) that are mostly self-contained and therefore easier to review.

6 Likes

@illuminati great proposal for the community :slight_smile:

Personally particularly interested in helping make any move towards improving back-up integration. Automated and easy system-wide back-ups would be awesome IMO. This GH thread about incremental backup started in 2015 and discussion started reviving here lately (summary).

@illuminati are you interested in this one about exploring the possibilities to improve Qubes back-up system ? Do you think it would fit as a first pilot as you suggested to launch ?

@adw do you think the backup component would meet the requirements and Qubes team goals ?

1 Like

I’m interested in improvements for backups, but I don’t think I could help out with that at the moment. Setting up an audit program is going to take up a lot of my free time, and I think it’s more of a priority issue for the community as a whole, especially with the recent concerns of possible state actors being behind the xz backdoor.

I’m not sure how incremental backups would fit into the scope of a pilot community audit program. Perhaps such a feature could be audited by the community when code is finalized and ready for general testing?

2 Likes

OMG this is awesome, thanks @PostedPortal

:smiley:

2 Likes

As @illuminati mentioned above, this is about auditing the existing code as it is right now, which sounds like it does not include the type of backup features you’re looking for, so I’m not sure if what you’re asking for is really what you want.

1 Like

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

3 Likes

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.

3 Likes

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

To which Rustybird replies :

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.

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. :stuck_out_tongue: 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 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!

3 Likes

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.

Better to ask @deeplow about setting up forum stuff.

1 Like

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

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?

1 Like

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

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

1 Like

:exploding_head: 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.


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.

2 Likes

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
1 Like