@Insurgo I took the liberty to move this discussion into its own thread. Hope you don’t mind.
3 Likes
And posts will continue to flow. This one is from 3h ago 
@demi: I am not sure packaging public keys is the solution. Teaching and taking by the hand is, while global documentation (@adw: core) explaining how to add GPG keys should also be core, IMHO.
1 Like
Tried real quick to try to do PoC wget-wrapper code snippet, and wanted insight on what is the best approach to get network info for Templates.
Without network
user@debian-11:~$ qubesdb-read /qubes-ip
Failed to read /qubes-ip
user@debian-11:~$ qubesdb-read /qubes-gateway
Failed to read /qubes-gateway
user@debian-11:~$ qubesdb-read /type
TemplateVM
With network:
user@debian-11-networked:~$ qubesdb-read /qubes-gateway
10.137.0.8
user@debian-11-networked:~$ qubesdb-read /qubes-ip
10.137.0.51
user@debian-11-networked:~$ qubesdb-read /type
TemplateVM
So basically:
- wget could be an alias to wget-wrapper.
- curl could be an alias to curl-wapper
-
wget-wrapperandcurl-wrappercould check forqubesdb-read /qubes-gatewayandqubesdb-read /type. If TemplateVM and have a gateway, warn the user that this is really insecure and ask for confirmation prior of continuing. If TemplateVM and no gateway, exit saying that-proxycountrpart should be used.
Thoughts?
Exactly this. The power of Qubes is that it does not change most workflows which people got used to – and still provides unbelievable security. I use it as if I used an ordinary Linux system (but with several independent enclaves).
I’m afraid that complications like offline templates may put people away. Adding fake curl makes things even more complicated in my opinion and goes against the policy of not changing the underlying operating systems. Please do not go this way. Same with GPG keys.
My suggestion is to allow as an option non-default, networked templates in order to install software outside the default repositories. Such option should be visible somewhere in the UI, e.g., a tick while creating a template. Also mention it in the documentation as an option for installing special software.
1 Like
I never get why getting functional ideas is so complicated.
- Templates implement a proxy. It is only hidden, but used by OS software installer, which are modified to wrap around the proxy
- The idea here is not to change the underlying operating system. But to wrap security measures and ease deployment.
- Giving Templates a network gateway should be last resort, really.
- Asking the user to download GPG Keys externally, qvm-copy them and then modify upstream installation instructions is a non-sensical and requires the users to be rtech-savvy, which is not the goal of Qubes, but a side effect of problems like those. We should lower friction (UX), without making it less secure.
[Looks like some of the ideas in this post were anticipated while I was typing it.]
Let’s step back for a moment. Why don’t templates have unrestricted network access anymore? To prevent users from doing dangerous things in templates, right? But this assumes that all templates are at the same ultra-high-trust security level, which isn’t realistic. In practice, many users want to have templates of varying trust levels. Some are ultimately trusted, some aren’t trusted very much at all, and others are in-between. Sometimes, users need to use some untrusted piece of software in a couple qubes, but they don’t trust it at all. They want to be able to install it in an untrusted template for use with untrusted app qubes in order to keep all of that separate from their trusted templates and app qubes. The problem is that the current one-size-fits-all policy of “no templates are allowed to have direct network access” doesn’t support this common use case. That’s what’s driving you to find workarounds.
See, that’s the thing. I’m not convinced that is the actual problem. That sounds more like a symptom of the underlying problem, which is the one-size-fits-all nature of the way template networking works. Suppose we added a feature where you could toggle on “unsafe mode” for a template, and doing so grants that template normal network access just like an app qube (and just like templates used to work back in the day). Then users would be able to add new keys to templates and install software in them the normal ways, without any proxy hoops to jump through. Of course, there should be a big red warning when enabling “unsafe mode” that explains just what you’re getting yourself into. And, if you prefer, you can instead have this “unsafe mode” (or whatever you’d like to call it) implement the networked-but-firewalled system we had more recently in Qubes history, where the user had to choose to allow temporary network access for 10-15 mins or however long.
Either way, we have the UX challenge of having to explain to the user why their desire to install (or enable the installation of) non-default-repo software is a security risk.
My point here isn’t that one solution would be better than the other, but rather that we should understand the nature of the underlying problem.
I can see the appeal of this approach, since the “direct network access” approach allows for doing “stupid” things in templates, but the trade-off is that the workaround is less robust. It’s only a matter of time until users start asking how to install software that doesn’t work with wget-proxy or curl-proxy. (Actually, they already are.)
Of course, this is just a specific instance of the more general trade-off between security and convenience.
Realistically, many (not all) users will follow upstream instructions without understanding them. Since those commands could do anything, this is tantamount to doing “crazy stuff” in a template. In other words, executing commands you don’t understand in a template is effectively doing crazy stuff in that template. But look, I’m not here to argue about whether it’s “crazy” or not. That’s beside the point. The point is that users want untrusted templates, but the current no-networking safeguard applies to all templates, hindering that use case.
This is not necessarily a mistake. After all, Qubes OS should be secure by default, so defaulting to the most secure assumptions for templates makes some sense. But that doesn’t change the reality that many users will continue to want untrusted templates and be stymied.
I agree with the user-education philosophy, but realistically, many users’ understanding will only get as far as “replacing wget with wget-proxy makes it work for some reason, so I just do that to make it work.”
Also, many users are allergic to the command line, so this is still a stepping stone to a GUI solution.
2 Likes
This is not about the default configuration. Default offline default templates are probably fine, although when I discovered them, I anticipated that many non-technical people will be annoyed by that.
I guess our disagreement comes from your expectation that Qubes should force extreme (relative of course) security, usability and freedom be damned. I disagree with that, and agree with @adw that a lower degree of security is a legitimate use case, because it’s a requirement for many users. Moreover, when someone switches to Qubes from a less secure systems, I don’t expect that they will immediately have maximally secure settings, but improve their security step by step. Starting from less secure templates might be a good starting point and is much better than any ordinary OS.
But changing curl utility does change the OS, doesn’t it?
First, thanks @adw for your thorough answer. On above quote, I do understand the GUI approach to install software already present in configured repositories. My whole idea challenge here is how to add additional repositories. Users allergic to terminal I can understand, but the GUI approach won’t resolve this same basic problem i’m trying to tackle here. Real customers recurrent problems!
And to me, that would be good enough. The user would need to do it manually, while wget-proxy could also give that same fat warning reminding the user that he is bypassing security measures on a trusted template.
I am not sure if its because I go into too much details that I do not make my point straight, reading @adw and @fsflover reactions to wrapper approach. This additional step would permit untrusted Templates to do whatever the user wants if we decide to (TemplateVM being detected by qubesdb-read /type, while networked state is detected by qubesdb-read /qubes-gateway).
What are other used methods (not curl/wget)?
Anyway, should I go forward with a PoC or this whole idea just doesn’t fit the Qubes OS vision (what is the plan for GUI GPG key import?)? Or am I not making my point clear enough?
I honestly don’t get what the problem is.
-
users can create / clone as many templates as they like, deciding themselves which ones are trusted and which are untrusted
-
the user can already assign a netvm to any template using the GUI should they wish to … no special checkbox or change required
-
the user can already use
curl --proxy http://127.0.0.1:8082/in any template and it will work.
This is all available today and was since I joined this community in 2017 (R3.2). It’s documented in a hundred places. The only way to make this any easier are respective salt formula to be discovered, trusted and used by users.
1 Like
And my attempt was to address both use cases. There is nothing wrong with standalone qubes or insecure templates. But we are mixing things here. Step back: TemplateVMs are OS layer where nothing untrusted should be ran and shared amongst qubes having that base trust level in mind . A user can decide for himself to clone a Template qube and install whatever he wants there. No problem. But I do not see anything wrong into users wanting to deploy a new repository (including GPG public key…) into a trusted Template if that Template being debian-11 is a conscious choice and installing Signal repository there is ok. Nothing is ran by the deb package, nothing autostarts… Fits the bill. Going into other examples will give different results. But in that use case, like many others, the user should be able to download that GPG key without having to mess around.
The idea with the wrapper script would be to warn the user that what he is doing is actually to download something in the Template. If the user learns that calling wget-proxy actually downloads (bypass) no-network policy, but the big fat warning is still there (@fsflover: an alias is just a way to call the expected binary. You could set aliases of all sorts… alias ls="ls --color" being a shitty example, where alias curl=curl-wrapper would pass the command line from curl to curl-wrapper in all cases). So having a wrapper on dangerous commands, and modulate behavior depending of environement (qubesdb-read to the rescue) would fit both needs without too much complexity…)
- .bashrc would append the aliases
- curl-wrapper and wget-wrapper would contain the logic to deal specifically with TemplateVM type, and deal differently if there is gateway (network) or not.
- curl-proxy and wget-proxy would not be called automatically, but the wrappers would invite users to adapt their commands when typed in TemplateVMs to confirm their understanding of the risks.
Otherwise, I have no other idea, folks. I just know that GUI installer will have to deal with this issue as well, and that most if not all customers have problems.
And no @Sven…
As said in past comments, that would work without any change when upstream instructions are doing it ok, but if the call is wget -O- blablah, the user will be confused and annoyed and will ask for help… Once again, this is why secure wrappers would fit the bill, but seeing all this reluctance makes me doubt of the approach to resolve the real problem while people seem to mix things.
Non-technical users won’t know what to do! Right? We agree on that? No. Signal not being installable is not a good solution. And going with other software alternatives flatpak/snap/standalone is not a good approach because the user never knows if there are updates. Repositories, managed upstream, are still the best solution, IMOH. And installing GPG keys should not be a burden, untrusted/trusted templates not being a debate here. Something working for all cases should be possible… and what I was trying to achieve.
Oh, wow, you’re right! I never had a reason to try it myself. I just saw the pages of posts from confused users over the years and all the replies suggesting jumping through weird hoops, so naturally I assumed there must not be a trivially easy solution like simply… giving the template network access. There is no problem after all, then.
However, I also never encountered this in the official documentation. Seems like we should at least document this on the how to install software page. I just noticed that this section is out-of-date, since it still references changing only the template’s firewall rules, which of course won’t solve anything when the template has no NetVM.
1 Like
@Insurgo, what about this solution (using Signal as an example)?
User instructions:
- In the template’s settings, change Networking from
default (none) (current)tosys-firewall. - Open a terminal in that template.
- Follow the Signal website’s instructions.
Much simpler, no?
I’m just trying to get a concrete sense of where any remaining disagreements lie.
1 Like
Oh, I see you already addressed this a bit above.
But what’s the point of installing the Signal repository without using it to install the Signal app? The repository by itself does nothing unless it is used for installing packages, so there is no reason for it to exist in templates in which Signal is not installed.
…and then we’re back to just installing Signal in the template the normal way.
In this case,
Should become:
- Clone your template first
- In the new template’s settings, change Networking from
default (none) (current)tosys-firewall - Go to firewall rules tab, select “Limit outgoing internet connection to…”
- Tick “Allow full access for 5 minutes”
- Open a terminal in that template.
- Follow the Signal website’s instructions.
Mix/match 5 minutes with instructions to deactivate Template access when done. (But keep in mind that most users won’t turn it off, and that a lot of them then report weird behaviors from their qubes based on Templates they swear having be diligent but their bash history proves otherwise).
I suppose I had too many bad experiences with customers, which would go in all directions linked to a Template that was exposed to the internet without knowing the past exposure of such template. Users do errors. They will launch firefox that is assigned by default with the template (which I remove shortcut). They will type commands in Template that was aimed to be typed in qubes afterward. My background goes in the direction of limiting what can happen by default in a Template, pushing forward prevention mechanisms and making sure users understand what they are doing, but a lot do not understand. So limiting access to internet (as a big no) while permitting to convert generally simple instuctions (given by software providers) should be permitted with easy to understand swaps in commands. While still not permitting Firefox or any other installed software to be able to access the internet. But that is what I learned in the past years. I would love those users (which a lot of them are vulnerable and need those protections) to be safe by default, while not preventing them to actually do what they want to do.
If you have any improvements to suggest to push me into doing a PoC, let me know.
2 Likes
Please allow me to leave this here for all the lost souls finding this thread in an attempt to install signal:
#!/bin/bash
min_template=debian-11-minimal
signal_template=deb-11-signal
# clone
qvm-clone $min_template $signal_template
# install networking, curl, notification daemon & nautilus
qvm-run --pass-io -u root $signal_template "apt install --no-install-recommends qubes-core-agent-passwordless-root qubes-core-agent-networking curl xfce4-notifyd nautilus qubes-core-agent-nautilus zenity -y"
# add signal key & repo
qvm-run --pass-io -u root $signal_template "curl --proxy http://127.0.0.1:8082/ -s https://updates.signal.org/desktop/apt/keys.asc | apt-key add -"
qvm-run --pass-io -u root $signal_template 'echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | tee -a /etc/apt/sources.list.d/signal-xenial.list'
# update & install signal
qvm-run --pass-io -u root $signal_template "apt update && apt full-upgrade -y && apt install --no-install-recommends signal-desktop -y && poweroff"
This will obviously also work with a debian-10, debian-10-minimal or a debian-11 template. The notification daemon is required, otherwise signal will hang the first time you get a message and the focus was away from the app. Nautilus is not required but obviously useful when handling files.
2 Likes
Yeah, I understand. This is also the rationale for limiting template access in the first place.
Well, as for the PoC, that’s really @marmarek’s call.
And here we go the path of redoing guides to install specific softwares. Sigh.
Sorry. Didn’t want to upset you. In case of signal I too think that we should probably just add the repository to the debian-11 template. Not as a general solution, but recognizing that Qubes OS users are in fact highly likely to be signal users too. On the other hand this one concession would probably open the flood gates for all kinds of requests … 
Upstream instructions are not unified! Without unified solution, it means
- Upstream should provide qubes related instructions (nope)
- Users without clear understanding of piping, tools used (wget? what? gpg? curl? tee? what?)
The general idea behind my proposition is based on accepted trust of upstream installation instructions (not to be confounded with commands given on other sources).
And then we open the gates of the old persona problem which is to have different templates downloadable/installable at OS install to fit different use cases with those repositories/softwares already installed. I’m not against the idea. But the current proposition was aimed at lowering the bar for users just wanting to follow as cose as possible upstream instructions.
Reminder. Signal instructions could simply be:
- follow upstream trustable instructions.
- Open Template Terminal
- replace wget by wget-proxy, curl by curl-proxy where written.
- shutdown Template when installation is over.
- Assign application to the qube that application is aimed to be used.
Users go on, says ok, ok, I can do this and then…
wget-proxy -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg
cat signal-desktop-keyring.gpg | sudo tee -a /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' |\
sudo tee -a /etc/apt/sources.list.d/signal-xenial.list
sudo apt update && sudo apt install signal-desktop
He waits. shutdowns the template. Assign Signal to qube. Run it and…
Wow. It just worked ™.
He loves Qubes. Doesn’t doubt of the OEM who prepared his laptop of having broke the internet… He feels confident about life. And goes back at using applications, knowing it will be updated as any other.
(while we limited the possible impact of having followed shitty instructions downloading stuff to be autoran in all used qubes by following randomly found instructions, or having access to internet for anything else then wget and curl through wrappers using the proxy).
Bonus: he can generalize the concept instead of searching for answers, and then type obscure commands that were trusted because given by @sven on a random post on the forum. Who is @Sven ? Should he be trusted? I feel we are going in the opposite direction. Don’t get me wrong, I reviewed your commands and they are fine.
But… The absolute thing we do not want is users typing randomly found commands in forums with a template having full internet access!!!
The goal desired is journalists/whisleblowers not being tekksavvy being able to get home to commands translation, hand on on their shitty internet connection over tor and be able to install needed software without any complication, without opening holes in their templates, without them having to understand all the architecture, without them having to know qvm-run (that is teksavvy btw!!!) and just… seriously, just, be able to trust the open source software supply chain, understand rudiments of GPG and have just works ™ without looseing up security of their system without having to worry and trust who they should trust! You use Signal? Trust their instructions. Not a random post on the internet. That would be my ideal.
Now, the user will memorize weird process of replacing wget (what?) with wget-proxy (what? stupid Qubes, making complicated things even more complicated). Will it help security? I don’t think so. Instead, explicitly asking a user to create a dedicated non-trusted template should make them think about compartmentalization.
Indeed, it makes the cloned template less secure. But it unifies the installation experience, provides an easy onboarding to Qubes and opens a path to further secure the OS later. Remember, Qubes is a reasonably secure OS. This is how I understand it.
In my opinion, your suggestion is relevant for advanced uesrs and not for newbies. The former can already follow @Sven’s instructions (and verify them themselves), while the latter will simply be turned away by unnecessary complexity, which Qubes forces on them. Qubes is complex enough already without it.
I don’t think it’s a right place for this script, but it looks like an extremely helpful thing to me. If you could share your other scripts like this in a dedicated thread, you would help a lot of semi-advanced users, including me.
This is not necessarily true. I personally hate Signal for it’s walled-garden policy and for forcing users into Android or iOS. Please do not make a special case for it in Qubes.