docs encourage usage of Standalone VM

[deeplow]

Description

TL;DR: Development environment has root partition persistence at the same time it has passwordless sudo

Qubes' architecture (particularly non-persistent root partition) allows for distrusting the kernel's privege escalation mechanisms (giving us the convenient "passwordless sudo"). But when creating a StandaloneVM those mechanism's are no longer effective.

The docs encourage the creation of a StandaloneVM for development. For the understandable reasons of faster development. So far, from what I've seen in the project, after the initial there aren't that many changes one has to do with the packages because it is all with virtual environments.

If anyone is in the position where that is a problem, then I think they would have the knowldege to convert it to a StandaloneVM (which is quite simple. The same cannot be said for the reverse, I think)

Comments

Any solution here will increase the barrier of entry of a what is already quite a high one (In my case it took me a week just to get everything right with the staging and dev environments - with an bug in the path).

So I don't know if this is something that you may want to address, but I just felt the need to bring it up.

If this is to be changed, I'd suggest bellow 3 possible approaches.

Approach 1 | little note in docs

Add note to the docs to encourage future developers opting for a AppVM instead for development while pointing them to the relevant qubes documentation on the implications (this would require minimal changes to the docs)

Approach 2 | AppVMs in docs

Change the docs to configure things as AppVMs.

Approach 3 | Replacing passwordless root access with Dom0 user prompt

Add a step that directs the user to: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt which is what I currently do. But it's tricky and if the user messes up a step they could brick the VM (in the sense that they could get locked out)

[emkll]

Thanks for the report @deeplow !

Option 2 sounds best to me, but as you point out, more onerous than option 1 (which is a great immediate and relatively straightforward fix). I'd be interested in other's thoughts on the topic. Another approach we've discussed in the past, similar to approach 2, is shipping a dev template (installed in dom0, similar to the securedrop-workstation template), which would contain all the packages a developer would need to get started (and can spawn AppVMs or DispVMs as appropriate)

[conorsch]

Agreed that recommending an AppVM is consistent with the Qubes way. Over time I've accrued a few customizations to the dev template I use, particularly increasing disk space and using bind dirs for the docker image layers, so one doesn't have to re-pull every docker image daily. If folks have strong feelings about customizations they've made to work on SD in Qubes, please add them here, otherwise a small docs update of StandaloneVM -> AppVM is a good next step.

[conorsch]

increasing disk space and using bind dirs for the docker image layers, so one doesn't have to re-pull every docker image daily

$ cat /rw/config/qubes-bind-dirs.d/50_user.conf 
binds+=( '/var/lib/docker' )

That'll cause the docker images to stick around, which has its ups and downs. If you opt in to that setup, consider resizing the private volume to accommodate the storage: qvm-volume resize sd-dev:private 10G or similar.

[eloquence]

This was a keyword misfire on freedomofpress/securedrop#5269 (which contained the phrase "did not attempt to resolve" GitHub interpreted as resolving), reopening.

[gonzalo-bulnes]

For what is worth, I too have experimented with AppVM sd-dev, that I partly set up from a Salt formula. While my formula is not comprehensive (nor robust!) and I use no custom settings on that machine, I must say that I like the convenience of being able to set up sd-dev in a mostly automated way.

The configuration that @conorsch mentions to cache Docker data seems like a very significant improvement to me, as would an option to record history.

For what is worth, I think that providing some level of automation when explaining how to set up sd-dev as an ApppVM could be an interesting way to make initial set up quick, while introducing common Qubes OS tooling in a useful way to contributors new to it.