I am already uncomfortable with the fact that any program running in a template can get network access to any destination by simply using the proxy at port 8082. I understand that I can address this by setting a different policy and/or setting firewall rules for the qube that hosts the UpdateProxy. However, we are talking about the default here.
The issue discussed in this thread is of course real, but it ought to be addressed by educating users, better documentation, community support and hopefully one day a “salt store” offering trusted recipes to install software and configure Qubes OS (@unman works on this I think). In the meantime maybe by adding some popular application repositories and keys to the default install as @Demi proposed. Maybe.
What the wrappers proposed here aim at is to allow users to follow instructions they don’t understand to install who knows what software on a system they choose for heightened security. And the justification that they might otherwise do even worse things is none at all. There is only so much Qubes OS can do to protect users. Doing less to prevent them from becoming frustrated and sabotaging themselves can’t really be an argument – can it?
And maybe even more by the fact of a most user friendly action imagined - choosing netVM in Qube Settings for the template. Setting proxy is somewhat advanced, but the former is so easy and teasing.
My intention wasn’t to discourage @Insurgo to continue brainstorming, but only to bring in user’s point of view.
I just see this as a safety feature as any other in Qubes, which the one have to learn how to workaround if (s)he wants to use Qubes. I’m at the forum too short, but I haven’t seen a safety feature that wasn’t challenged or asked how to be circumvented. Shared folders/storages, VMs communicating to each other directly, bypassing safety dialog boxes, remote access to dom0, installing whatever in templates, installing whatever in dom0, copying from/to dom0 more friendly, escaping using CTRL+SHIFT+c/v, etc, etc… And probably all of them, I’ll repeat myself here, they all know what they’re doing, or nah, it won’t happen to them, or they don’t have to hide anything, anyway.
Well, there are users too that will not challenge any of these, that adopted the logic and want to see Qubes even more tighter in terms of security.
There is simply not much space for conformism with the astronaut’s suit while in space
If the proxy was logging downloaded content, the principles of “trust but inspect” could be applied after the fact, if using such proxy. Giving total network access, without passing by the proxy, is the other option. So here, as of now, we have an unmonitored proxy, that users bypass per instructions to install whatever they want. I still think that enforcing a proxy is a pretty good way to do things. Yes, anything knowing where the proxy is (apt/dnf) can use it. But the problem here is not the safety mechanism, but the lack of current auditing possibilities of what went through it.
The approach of exposing the proxy system wide is the counter-proposition given by @marmarekhere. If implemented, the user could call enable-network-proxy which would give system wide internet access through the proxy. Once again, I would not personally have a problem here (proxy is used, no direct access per Template assignation of a gateway), IF tinyproxy was logging url accessed.
My latest proposition (I feel people do not read) is to pause (3 seconds) each wget/curl commands typed in Template terminal to tell the user what is wget/curl, and that if not intercepted, xyz file will be downloaded per past command (in script or command line). This is a non-blocking proposal. A script calling wget/curl would be intercepted by the wrapper, pausing for 3 seconds at each wget/curl call.
By implementing 3 different behaviors (TemplateVM without network assigned, TemplateVM with network assigned, qubes), everything calling wget/wget is intercepted by the wrappers, where only TemplateVMs have different paths of operation: Non-Networked Template informs the user that curl-proxy/wget-proxy will be called with the URL in 3 seconds, giving the user possibility to CTRL-C, while networked TemplateVM gives a warning, pause for 3 seconds with the wget/curl URL that will be downloaded next. Application Qubes just receives a message saying that they are going to download something and doesn’t pause. The idea here is for the user to have a chance to stop each individual downloads that would happen in a script ran under a TemplateVMwhile not blocking the user from downloading stuff with curl/wget (since most upstream instructions are using those 2 common download tools), permitting scripts to still work. The blocking/annoying approach would be to ask user for confirmation, which would break scripts.
@Sven We could go more advanced then this, but that would be more complicated to explain to users, which would otherwise just open wide internet access. For example, scripts are called in terminal in a different way. We could block that, so the user has to type commands one by one interactively on the terminal, instead of pausing for 3 seconds each time curl/wget is called. But the user would get even more frustrated, and would assign network to template even more easily.
Maybe its time to just ask basics and get global consent on basic principles.
@sven: Do you agree that having tinyproxy logs would permit core documentation to give guidelines to be able to inspect in retrospect what was downloaded in a Template, since an external proxy is used? Do we agree that since that proxy is external, it is more complicate to obfuscate network accesses and would give the possibility to confirm/infirm trusted state of said Template?
We agree that Templates can access the internet if commands explicitly express how to use defined proxy in their wget/curl commands.
Compromise of such Templates through internet downloaded stuff would require past actions to have defined system wide bypasses, explicitely defining how to use such proxy, and commands ran in TemplateVM outside of simply downloading required stuff, not running there anything else
@Sven The proposed solution, pausing for 3 seconds, warning users of downloads that will happen in TemplateVMs (with proxy if no network, without proxy if network is given) was my best idea to deal with all use cases. A user knowing what he is doing will most probably give direct internet access to cloned Template, and the wrapper would pause for 3 seconds prior of calling wget/curl. No big deal. Both TemplateVMs use case can still call wget-proxy and curl-proxy, which is not a regression following your comment on security, since bypasses measures for commands to directly use proxy could still be used by code snippets trying to circumvent TemplateVM to download stuff. But the person writing installation scripts could now simplify them by calling wget-proxy and curl-proxy directly, bypassing the 3 seconds warning pause.
Makes sense? Otherwise:
Would be helpful if GPG+Repositories are deployed. But then again, for having done that in the past, I received a lot of complaints, which some in this thread already shown same disagreement: Why would we do that choice for the user of deploying Signal repository? (Why Qubes would be choosing to deploy Signal?)
Deploying “persona” related packages (salt recipes, repositories, GPG keys, even personalized TemplateVMs including the precedent predeployed) is an old dream going back to 2019 if I recall well.
But meanwhile, each time a user installs/reinstalls (Q4.1) with new templates (time to get back clean and install repositories and software again) is a big burden for users, which didn’t thought they would have to do it again, and forgot the complications they had to deal with years ago. Some will have made some scripts to ease the process (not a lot know salt), but in most cases following upstream software installation documentation is ok. The problem arises when the user needs to find security measures circumvention.
I hope we agree here that users should be able to just follow Signal/Session guides. Having a 3 second warning prior of having expected result is, I think, a pretty correct result. On that, I do not understand this thread reluctance.
This is why I advocate for curl-proxy and wget-proxy (which basically are better defaults then calling curl and wget with obscure and unsafe options), while wrappers are teaching them how to script this properly, and do simple substitutions when following upstream instructions, which would nullify the need from Qubes to package GPG keys and repositories (maintainership of those added) and continue to give Qubes OS freedom, while warning them about what they are going to do prior of actually impacting their templates.
@enmus It is hard to implement security without impacting convenience. We are talking about safer default (proxy is there now, which is a good thing, while not permitting proper audit to serve its full purpose, which is the problem here).
In short
We need tinyproxy logs so core documentation can tell users to inspect logs prior of trusting a new created/modified Template. This proxy could become a better ally, not something most users want to circumvent because its in the way. We should wrap around it better
We should not push users to give wide internet access to Templates but in last resort
We should guide users in their learning steps, reducing friction without compromising security principles
@marmarek Agreed (apt-cache-ng being another subject altogether I do not want to mix here). We could output timestamps in the wrappers to better match what would be in tinyproxy entries. Point here, if there is 4 entrees in tinyproxy where only 3 prompts were given in Template, some questions should arise from the user and inspection of code snippet ran should occur. But yet again, nothing will be perfect. Just improved.
Please help me improve this PoC. (tar.gz archive, instructions below)
This is the blocking version of what was posted above, but archived for convenience of testing. (Non-Networked Template will prevent automatic download and tell the user to replace wget/curl to wget-proxy/curl-proxy manually from command line).
The non-blocking curl-wrapper example (translating curl to curl-proxy calls automatically on non-networked TemplateVM) is here.
Was created by:
user@debian-11:/$ sudo tar zcvf wget-curl-wrappers-config-changes-debian.tar.gz /usr/bin/curl-proxy /usr/bin/curl-wrapper /usr/bin/wget-wrapper /usr/bin/wget-proxy /etc/profile.d/download-wrappers-aliases.sh /etc/bash.bashrc
tar: Removing leading `/' from member names
/usr/bin/curl-proxy
tar: Removing leading `/' from hard link targets
/usr/bin/curl-wrapper
/usr/bin/wget-wrapper
/usr/bin/wget-proxy
/etc/profile.d/download-wrappers-aliases.sh
/etc/bash.bashrc
So you can inspect code by downloading/extracting it locally in any qube directory.
You can test it by cloning debian-11 to debian-11-proxytest or whatever, and then copying the downloaded archive to your cloned debian-11-proxytest TemplateVM (qvm-copy from command line or righ-clicking in Files application from the qube that downloaded the archive):
cd /
sha256sum ~/QubesIncoming/NameOfOriginQube/wget-curl-wrappers-config-changes-debian.tar.gz
397c6e3e8e792a4fcb48c7401b575dab30e51afb58eea4f7ee350a62a7aa2fb4 ~/QubesIncoming/NameOfOriginQube/wget-curl-wrappers-config-changes-debian.tar.gz
sudo tar zxvf ~/QubesIncoming/NameOfOriginQube/wget-curl-wrappers-config-changes-debian.tar.gz
Reboot Template (or just open a new terminal.) /etc/bash.bashrc will reload /etc/profie.d/*.sh and the aliases should be there already working so that curl/wget are replaced by curl-wrapper/wget-wrapper, which you can confirm by typing alias in the terminal.
Then try calling curl and wget to download stuff:
TemplateVM without assigned network (default)
TemplateVM with assigned network (core instructions)
from created qubes depending on cloned template.
Please report experience/frustrations/desired improvements: what you would like to be the Qubes default TemplateVM behavior dealing with command line downloaders and why.
@Marmarek: Breaking what, where, how? We take the original command arguments of original command and simply reinject them into the real wget/curl. I do not understand what could break?
On qubes depending of Template and wrapper scripts the following is called:
Which in example output:
From what I get, a little more transparency might be needed here for all console output:
user@wrapper-test:~$ wget
wget-wrapper: wget download attempt not in TemplateVM. Continuing...
wget: missing URL
Usage: wget [OPTION]... [URL]...
Try `wget --help' for more options.
user@wrapper-test:~$ curl
curl-wrapper: curl download attempt not in TemplateVM. Continuing...
curl: try 'curl --help' or 'curl --manual' for more information
Might be enough? Same applying to all, stating that this output is coming from wrappers for more transparency, maybe?
@marmarek I get your point, while disagreeing. A wrapper per downloader, not hard to understand aliases pointing to the wrappers seems the best approach to me. Unless I do not get your concern, which I would be really happy to hear.
I’m very late to this, and I’ve only skimmed the thread, but I’ll put in my 2 cents worth.
The problem that Qubes faces is how to make it easy to do the right
thing, and not make it easy to do the wrong thing.
At one time tinyproxy had filters that aimed to limit the use to which
it could be put. I thought this was good. The filters were removed at
Patrick’s argument, to make it easier for users to use 3rd party update
repos. I thought this was a mistake - I still do. Since this can be
configured relatively easily, it’s not a great issue.
I’ve said before that I find myself at odds with some of the direction
that Qubes is taking. This may be a cultural issue. I have found myself
at odds with Nina more than once because of this.
I do not think that users are the right people to “push this forward” -
at least, not users who find this a “total annoyance”.
What is the issue here?
A user sees instructions on the internet for installing some piece of
software, tries to apply them in Qubes, and finds they do not work.
As Sven has already pointed out, these issues have been covered many times,
and the solutions are easily available. But apparently some users are
unable to find them, don’t ask for advice.
Frankly, I think it is the wrong thing to make it easier for those users
to install 3rd party software by themselves. It does them no favours and
it does Qubes no good.
The way I do this, is first, by customising the install for new users
after working through what software they wish to use; secondly, by
education about how to use Qubes, and how things are put together for
security, and finally, by providing packaged solutions for installing
3rd party software.
I ask people to use the support I provide, and emphasise that this is
safer for them. Every discussion is a chance to increase users
understanding of Qubes.
This has the advantage for me, in fewer support calls, and for users, in
straightforward ways of installing 3rd party software. Not at all
a generic solution, but in my experience, there’s a limited range of
software that ordinary users want to install, that isn’t available in
the main repos.
This is my experience.
I quite like Mareks suggestion - I’ve used it before myself, and it has
the advantage of applying in that case, not generically. (I see this
as an advantage.)
I don’t like the idea of having user’s blindly follow instructions in
Qubes, when they are already blindly following instructions.
I often introduce Qubes to people as a luxury sports car. Before they
can drive it away they need some training, some practice, and they need
to take it slow to start with.
I warn people that they do not want to end up as a YouTube crash video for
people to laugh at. That helps to bring the message home.
For at risk users, the danger is even higher of course.
Does it need to be said that this is entirely my view, based on my
experience?
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
I’m a firm believer, from experience as said multiple time in this thread, of complete disasters from users learning their ways into learning Qubes. This is why/where I think this would greatly help.
I would definitely not go in the path of a wrapper blocking “.sh”/“.bin” or doing anything intrusive. But I really believe that since wget/curl are part of all external software installation guide, we would be helping everyone by implementing a global warning/stop gap.
Two versions here of the wrappers:
One exiting when in a non-networked Template, suggesting user to call wget-proxy/curl-proxy directly for the command echoed back on screen. Users following installation guides will be able to confirm easily that this is what they intended to do, and what is expected to happen next, and simply rewrite the command, manually changing wget->wget-proxy (which implements proxy usage).
Second solution is to auto-translate the wget/curl calls in non-networked Template, with a warning still given to the user which has 3 seconds to cancel the download that is going to happen.
Other ideas that came up:
@Marmarek solution is spot on, requires users to see wget/curl failing, search online and activate global proxy momentarily. The user will not be informed of why it failed, will learn the hard way to finally give global access to the internet, not just for specific wget/curl calls. I’m not convinced of the approach to be helping.
@adw modified core Qubes installation instructions to push users into cloning templates, and to assign network with blocking by default, while limiting network access for a time limit. @marmarek approach is better then currently mainstream documentation, while I still believe that those curl/wget calls, which are the main problems in Templates in my opinion, should be dealt with more education prior of the actions being taken and actually impacting the Template and depending qubes.
@fepitre@Demi approach is to package GPG keys (the most problematic part of installing new repos and having those software maintained and upgraded automatically per Qubes widget warnings) and maybe repository files for the most used additional software (I see debates coming)
What I came with is wrappers detecting if in a Networked/non-networked template or qube, aliases to those wrappers, and specialized wget-proxy/curl-proxy scripts calling the proxy directly for those different use cases.
For the end-users I serve, it would serve their needs. Which is pretty basic, and is to be able to install repositories matching their software needs. While also implementing stop-gaps when obscure scripts attemtping to download stuff are randomly ran by desperate users (yes, this is a thing that happens off hours by people becoming impatient and going crazy because upstream instructions do not work).
So my question @unman: What is the best way to address users needs of being able to install/test/play with Qubes, educate them on the spot while preventing stupid actions while not preventing them to do what they want to do? Yes, giving access to Template will work but is a radical solution (upstream core documentation). Activating proxy globally on non-networked Template VM is also radical, but temporary. Still not ideal. Going back to what Qubes was before and not implement a proxy and giving internet access by default should continue to be a no go. But users should be able to download a GPG key from upstream installation guide for a software they decided to trust. And for that, I really like the following output when attemtping to follow Signal installation guide:
But of course, depending of the consensual decision, it could become non-blocking, while sill educating the user which follows upstream guides (Session example here):
Can you point to discussions who have led to the changes?
You might be right here. UX is a big and complicated thing. And doing customer support constantly brings insight and humbles. There are so many cases where people need to do stuff and where it should just works ™ where they improvise and compromise their whole installation, landing in dom0 to fix things with shady instructions… That’s a thing, really. So the point here is to make it understandable. And I believe simple wrappers could come to the rescue. But I may be idealist. The more I dig into the forums (recent) the more I realize that maybe Terminal should have a well presented MOTD. Reminding them of the Template state (Networked/Non-Networked). And propose them options as a start. Still convinced wrappers for commands blocked are better then online documentation, where user gets lost. Anyway
The problem is that users are often asking for support after some damage is done. Reverting Templates are not always an option since they played hard. Sometimes the only solution is reinstalling, really. And not just the Template. Sometimes, they mess around networking so bad that they modified firewall rules, now have Qubes/Templates connected directly to sys-net, or even worse…
All of this, seriously, because Templates are not exposing their network limitation transparently, in terms of what it means and how to securely mitigate it properly. The best solution, to me, would be for users to call wget and curl from the command line, modifying the command line to use the proxy, understanding what they are doing. But that is chicken egg problem. Then to use curl-proxy and wget-proxy scripts, but then they could just use those directly still not understanding what they are doing. Wrappers, pausing prior of action, seems to me the best solution with some logging. From the wrapper scripts, and from tinyproxy.
Otherwise, I’m kinda out of ideas. As said before for software installer GUI, the same basic issue will continue to happen. This requires users to download GPG keys in another qube, pass it to Template, import it (which requires them to understand what they are doing). Otherwise open network access, locally or globally from Qubes setting for the Template. None of those solutions apply to the end user’s needs.
I thought those wrapper scripts would be challenge for improvement. But it seems that people prefer to think that users know what they are doing and opening up locally global proxy access or giving global access to Template is a better approach then educating users while they experiment. I have to admit i’m a bit confused by the reactions in this thread. Experienced users biases pushed upon newbies, like if we all forgot how it was, and is, unless we have to deal with non-teksavvy users, to remember, and put ourselves in our shoes again.
Let me flip that upside down:
Why a user should not be able to download GPG keys himself and require external support to do so, out of the box? And then, how can we let the user do such thing while preventing him to download malware from a random website from obscure documentation? My answer was that following trusted upstream software installation guides should be treated as equal to an obscure script, where the user would be prompted with a warning of what is going to happen next. That was my proposal to teach/coah/ease that phase, not requiring Qubes to deploy GPG keys/repositories/maintain that additionally.
Core documentation is clear enough on the risks of installing stuff in Templates. The Templates prevents obscure applications from being able to access internet by default. That implementation decision should take UX in consideration.
Maybe 3 seconds pause with big fat warning, even in red, is not enough prior of continuing with the download through proxy? Maybe the user needs to write the commands manually?
Then the argument is that knowing the address and port of the proxy already permits to bypass the security if a snippet specifies it. But still prevent user to do legitimate stuff.
Anyway, I feel i’m just repeating myself. @unman, your advice on what you think of those wrappers/proxy scripts/aliases are more then welcome. I still do not know what would be better.
I really appreciate what you are doing and I hope you have seen my past posts promoting and defending your solutions (Heads, PrivacyBeast). Am I not trying to be a pain.
However in this particular case I think we just have very different philosophy. No, I do not think users should just be able to follow Signal/Session guides. I do not think users should apply any terminal commands they do not fully understand. Not in a template, not in dom0. The place to learn / experiment is a disposable qube.
I would like to compare installing software that is not in the supported repositories with side loading an app on a phone or a Mac. You CAN do it, but you have to explicitly acknowledge what you are doing and actively create the environment for it to work.
In all cases it requires that you understand what you are doing. The repositories available in Qubes OS are inspected and signed by entities we have explicitly decided to trust, be it the Qubes OS team, Fedora or Debian teams. It’s not perfect but way safer than allowing an unskilled user downloading a backdoored version of whatever from a random website.
(the above link uses a capital i instead of an l … fortunately it appears the signal team has anticipated this obvious trick and registered signai.org too and forwards to the legit signal.org. In any case, I trust my point is made)
Because the more she messes up, the more she’ll blame.
We don’t have to express our experiences with real-life user support. We all have it exactly the same here.
And it goes that “annoyed” users for whatever mess they make, they will start to blame Qubes, then the hardware and eventually support.
I tested your scripts @Insurgo as proposed and everything worked as expected. Smooth. I had to replace wget with wget-proxy as asked.
But, frankly, from user’s perspective, I don’t see why the same warning can’t be integrated by devs, telling to insert --proxy http://127.0.0.1:8082 in order import to work, instead curl-proxy? The difference is in a few characters more to type, right?
That would spare us from support here too, if that is the goal. But I doubt it.
@sven: I get your point.
Unfortunately, I think the problem lies in the differences in philosophies, as you pointed out.
I see no problems from users cloning templates and specializing them for a less trusted use case.
I see no problem, and encourage, users to experiment that way. I actually created guides for curtomers, to do exactly that, and also created guides, per request from them, to install specific repositories, adding the famous curl-proxy and wget-proxy calls with their proxy arguments, for them to be able to actually install those specific softwares. But this is not scaling.
I see pertinence into having global guides, explaining parts of the commands so user understand what they are actually doing (wget/curl/gpg/tee/piping for redirection etc).
But the philosophy difference I think we disagree with is that by using Qubes to properly compartmentalize qubes and specializing their templates, an untrusted, but still followed guide, here Signal taken as a weird example of that, should be followable.
The dark spot here is again that Qubes prevents to do those normal actions to protect the user, where the alternative and upstream documented guidelines to do what they would expect to do, even if they now understand the commands to be typed, requires of them to shutdown to protection, temporarily by giving Template global proxy access (as accepted as a god solution previously per @unman to @marmarek implementation suggestion) as opposed to properly warn the user on the spot, while he is learning. Basically saying: “you are sure you are not doing something stupid here download this from there?” And then permitting the action.
We are actually going the other way, saying: you want to follow a guide you trust (with your example pointing to the fact that users should not click links but type urls themselves, which I agree) to justify that the instructions there should not be followed.
# NOTE: These instructions only work for 64 bit Debian-based
# Linux distributions such as Ubuntu, Mint etc.
# 1. Install our official public software signing key
wget -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
# 2. Add our repository to your list of repositories
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
# 3. Update your package database and install signal
sudo apt update && sudo apt install signal-desktop
There is no way for the user to trust anything else there but the fact that, after deep technical understanding, which we cannot ask from everybody deciding to trust Signal at the first place, has a deep understanding of GPG, apt signature verification on the downloaded binaries and all the technicalities going on there. Even if those understand the basics of gpg, understand that tee outputs the result and piping redirects output from one command to the next, they trust:
They can understand that they are typing commands to add a repository which points to the same exact domain name
They rely on apt downloading files from there and signature validation that will be checked from each package downloaded prior of installation against the public key they implicitely trusted.
Outside of that, we are going to software supply chain, trust chains and beliefs.
I think Signal is a bad example of this… In the sense, which can be generalized, that if you intend to use Element/Signal/Session/Wine/Wire/Whatever, you implicitely trust those software and their distribution mechanisms and update mechanisms, while not necessarily following their development practices nor follow their development commits and review processes etc.
You have to trust. Now, yes, those GPG keys could be deployed by Qubes in additional packages, with or without additional repositories definitions. But I still do not understand, i’m sorry, the justification of wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg
Failing for the user, in the present example. Without mixing everything again, Signal here decided to download without sudo. then decided that they would pipe in subsequent command with tee to produce the output file under /usr/…
Each guide will be different. Session in above example decided to call curl with sudo and redirect the output directly where needed with -so. Each guide is different.
My point here is trust.
A user deciding to use Signal or whatever software has implicit trust. The fact that he is using Qubes for it doesn’t mean he understands the whole shebang. It means, I think, that that user decided to compartmentalize its trust. Sometimes the user is required to have trust in things he must use (Zoom etc). And the documentation is good enough to be able to guide him into not mixing those untrusted app with trusted app in Templates.
But trust is implied, everywhere.
The difference here is that guides that are not provided by implicitly trusted software providers are yet today needed to be followed by users, since we cannot really ask software providers to provide special installation instuctions for Qubes users. Right now, we require of those users to continue to actually trust those software installation guides, but to deactivate Qubes protection, instead of adapting such protections for those instructions to be followed cautiously.
My take, in reply to yours @Sven is that a user should be able to follow Signal linux installation instructions, after having well understood that this software should not be mixed with debian-11 if he doesn’t understand what he is doing. The core guidelines should teach the users to inspect the URLs typed to be legit (how) and make sure that they are taken from non-obscure guides. This is again tricky. I know you well enough to know that you are technical enough to provide good instructions, here on the forum (in reference to your Signal instructions applied on top of debian-minimal), but I would have an inconfort asking users, or seeing users, follow that guide under dom0, instead of directly under cloned template. Those approaches have canyons between them in terms of needed understanding.
So yes. My guidelines would be. Trust, but verify.
Clone template to specialized one for desired common use case.
Verify source of software instructions. Is it really the website of the project?
Verify that the URLs proposed in installation guide are linked to the project domains.
Verify that the GPG key is downloaded from that same domain.
And have in the same page there some basics about dnf/apt repository package verification internals. But no. I would not block GPG public key download. Not sure we should wrap around specific file extensions or complexify the wrapper scripts/alias more. But still convinced that stop gaps are better then wget/curl simply failing without explanation.
Having MOTD, specifically in Templates, that warns users and summarizes the risks and options available to them to properly install software not in default repositories?
Having MOTD at least explain why wget/curl commands and/or why internet access is blocked? (So users don’t break things because they do not understand).
Provide @marmarek simple solution to provide an alias that exports the proxy globally for that terminal, but still have MOTD to explain the risks of using it?
Provide wrapper/proxy scripts, while MOTD still explaining to the user why internet is blocked?
Having MOTD clearly stating that
No software should be run in the template. (And Qubes removing Firefox shortcut deployed by default still today for Templates…)
That network access is not permitted by default unless proxy is passed to the commands directly for more security or
That toggle alias can be run to activate proxy usage globally, to be used with caution.
Well, from your suggestion both wget-proxy and curl-proxy should disappear, and curl-wrapper and wget-wrapper should output the replacement commands for the user to be able to use wget and curl, adding the good command line options. @enmus. Not against. What I want is for the users to do conscious choices and raise their awareness of what they are about to do. I already gave my stances multiple times here. I would prefer a non-blocking approach, adding delays and explanations (wrappers) to resolve User eXperience issues, without opening the door even wider for internet access. That is my wish and hope for an approach that would serve both advanced users and newbies, not preventing them to do what they want to do and use Qubes for what they aim Qubes to be used for.
The consensus of this thread participants goes against curl-proxy/wget-proxy scripts (each opponent preferring the end user to type manually the arguments needed for wget/curl to obtain the same goal, while more complex and needing the user to know at priori why those commands fail and what to do instead). I disagree, but I’m no dictator. Moving away of this implementation idea for the moment.
The actual proposition was having wrappers around aliases, the wrappers being the ones calling the curl-proxy and wget-proxy scripts. We cannot have wget/curl aliases pointing to wrapper scripts that would ask the user to call the original wget/curl commands that are actually calling alternatives per aliases defined.
This leads us into another approach, more informative then anything else, which could be in the form of a dynamic MOTD (Console welcome message, Message Of The Day) which could inform the user of the following, instead of taking them by the hand. (I disagree, but i’m no dictator).
I would recommend having MOTD in TemplateVMs explaining the current blocking security measures in place and ways to deal with them properly (they are in the Template Terminal for a reason, and this is where they can do damages). Saying:
Why TemplateVMs do not permit direct network access
Expose what is the proxy address
Warn the user to not run any application directly in this terminal
Software installation instructions won’t have wget/curl commands work, unless they append xyz to them with the proxy address above, and maybe help them some more
Incentivize them to not install anything from third party repositories in the Template shared amongst most of their trusted qubes. To duplicate the Template and do the desired installation there first to test it with a new qube created to use that new cloned Template where the installation occurred.
@unman@deeplow@ninavizz If you could talk a bit of UX internally around this, exchange a bit with @marmarek and come back with some direction, that would be greatly appreciated.
Well. As you might have saw, the proposed proxy scripts are doing a little more then just specifying the proxy, forcing TLS1.2 (cannot ask 1.3 because some things might break, while older HTTPS technologies should be dodged) where implementation of command arguments differs between curl/wget when specified per application:
@enmus Otherwise, the more global solution proposed by @marmarek opens global proxy usage for the current console, all new program instanciation being able to benefit of that exported proxy availability. This would be extremely convenient, not require more wrappers, but as said before many times in this thread, requires the user to only type trusted commands (since everything aware of that exported proxy now can use it, without any additional command line arguments needing to be specified):
In my personal opinion, I thought we did not want to expose global proxy nor network access to GUI Software installer (from other threads) because of downloaded thumbnails and other download artifacts. The scope I tried to implement being limited to external tools being used to download things from the command line only, per tools being whitelisted by those curl-proxy/wget-proxy. If a user is to type, at the end, manually:
I’m not sure why we would not want to have those helper scripts, like proposed, because too easy to use, while maybe ready to accept to have a enable-network-proxy defined alias that sets https_proxy=http://127.0.0.1:8082 environment variable for that terminal future launched programs to access the internet through the proxy… i’m a bit lost
My goal was, again, I repeat, to educate users into validating individual wget/curl calls used in all upstream software installation methods. Maybe the best way is to activate globally and not create wrappers, while I think we would miss a chance to do in situ training/awareness of users.
The MOTD should be short and to the point (limitations, risks, link to page on Qubes OS website).
Adding short explanations and links to well crafted guides all over Qubes OS: yes!
Having tutorials like the thing @deeplow is working on: yes yes yes!
… and salt store, unman’s repo’s, adding GPG keys (@Demi), the web page I swear I will publish soon about debian(-minimal) in Qubes OS, improving the FAQ, doing a better job of cross-linking the ever returning threads (e.g. How to install VPN?) as @fsflover is doing a lot.
Giving my contrib value, I already took too much liberty to write here. Whatever outcomes here, it’s on my favor of convenience.
Analyzing the topic, it is obvious that the common denominator to all of us is raising awareness. The methods are different, and I see it as an advantage, actually. People fail to protect their data as they rely mainly on IT solutions which aren’t contextually compatible and sufficient. Probably, the greatest number of security incidents are due to the exploitation of human actions which then cause the majority of security incidents.
I cannot recall at the moment what it was, but I clearly remember that if I were to allowed to use something (a command, an app, argh) I had to correctly answer to several questions regarding to proper using of that thing, whatever it was. Any wrong answer - no access while the next chance for the first use, but also the same amount of questions on the next use. After all correct answers on a first attempt, less, but harder questions on a next use. I was delighted more by the fact then with the need to use it. That’s how i might see raising awareness.
I wish I could remember what it was… I won’t make noise anymore.
Nope. That’d be Marek. I was just responding because you @mentioned me by name.
Human-readable output that explains the problem and offers solutions is great! Certainly much better than nothing at all. However, as I mentioned before, command-line-only solutions are probably a dead end in the long run, as it will all have to eventually be replaced by some kind of GUI solution. Does this mean it shouldn’t be done? No, I’m not saying that. Not making the perfect the enemy of the good. But whether it should be done depends on many factors, like how much of the devs’ time it would take, how much complexity it would add, what the alternatives are, how many users would be helped and by how much, etc. I don’t pretend to know the answers to these questions.
Actually, haven’t we shipped a (disabled-by-default) Google Chrome repo with templates for quite a while now, @marmarek? My understanding is that it’s purely for user convenience and because Google Chrome is so popular. So, there’s precedent for that sort of thing. It’s a bit of a dangerous path to start down, but it might be the least bad of many bad options.
Realistically, for most users, if they can’t use the software they need after making a reasonable effort, they will simply give up on Qubes and use something else. When I say “most” users, I don’t mean people who need security so badly that they are willing to go to great lengths. I mean people who value security up to a point. Where is that point? What counts as a “reasonable” effort? It’s different for everyone, but we can’t expect everyone to create a forum account and ask questions. For many people, that will be a bridge too far. Not every single Qubes user should have to personally interact with us in order to use our software. Only a minority should have to do that.
For example, only a certain number of people ask and answer questions on StackExchange, but orders of magnitude more benefit by finding those answers in search results. Most people need to be able to be “lurkers” who quickly find the answers they need when doing a quick web search without ever having to ask questions themselves, or else they will simply give up and choose an easier OS.
This is great, but unfortunately it can’t be a reality for the majority of users, because the majority of users will never have access to a personal one-on-one Qubes trainer. (I understand that this is just based on your personal experience. I am simply pointing out a relevant fact.)
Not exactly. There was already old documentation there directing users to change template firewall rules in order to allow unrestricted network access. This no longer makes sense, because templates no longer have NetVMs by default, which means you can’t meaningfully alter their firewall rules, unless you assign a NetVM first.
In my view, the doc change really just updates the old documentation so that it actually works using existing basic Qubes tools (e.g., VM compartmentalization, cloning, color labels, assigning and unassigning NetVMs, firewall rules.). This doesn’t mean it’s the only way that it can be done, but it’s one commonsense way to use the tools Qubes gives us, and it’s something Qubes users have been doing for many years.
There are many different possible approaches. For example, another method that hasn’t been discussed much here is downloading things in a disposable, then qvm-copying them into the template so that template networking never enters the picture. A user who does this might not even see any of the educational messaging you’re proposing.
I don’t see anything wrong with a user cloning an existing template, calling it “my-untrusted-template,” giving it a red label (assuming red means untrusted for this user), and using that template as a place to experiment. There’s no fundamental difference between a disposable qube and a qube the user manually deletes immediately after shutdown. The former is just a convenient implementation of the latter.
That’s an interesting analogy, but I think the key difference is that phones and Macs are both monolithic environments. For example, on my iPhone, each app is sandboxed, but I can’t create a separate “instance” of iOS. I only get one, and everything happens in that one place. In Qubes, on the other hand, I can have an unlimited (hardware-permitting) number of Debian, Fedora, Whonix, Windows, Arach, Gentoo, etc. VMs, each a world unto itself. It would be like if I had a phone that was running both Android and iOS, securely compartmentalized, and I side-loaded untrusted apps in Android while confining my sensitive activities to iOS.
Yeah, I’ve been thinking that Signal is an odd example. When I installed Signal, I think this is what I did:
Download the PGP key in a disposable and authenticate it to my satisfaction using out-of-band channels.
Clone a template just for Signal and qvm-copy in the now-sufficiently-trusted PGP key.
Start up Vim in the new template and manually enter the repo definition.
Something like apt update && apt install signal-desktop.
I never had a desire to wget or curl anything in the template or download anything except the PGP key (in a disposable). I’d like to think that this is one of the safest and simplest ways of installing Signal in Qubes, but I understand that this requires some background knowledge about Qubes and PGP and repos, so my experience is probably not representative.
Maybe Signal isn’t the best example because they offer a repo? I don’t know; I don’t really install anything that isn’t from a repo, so I’m probably not the target audience for this sort of thing.
Realistically, the easiest thing for users in the case of apps like Signal would be to ship the keys and repo definitions in templates by default, like we do with Google Chrome. I’m not necessarily saying we should do this; I’m just saying it would be easiest for users (which is not the only important thing, and maybe not even the most important thing).
This sounds pretty neat. I’m generally a fan of this sort of thing (namely, exposing the user to concise documentation at opportune times and places, like with informative tooltips).
It’s also worth emphasizing that most of the different approaches being discussed here aren’t mutually exclusive. It’s not as though we can only do one thing (though it’s usually worth asking whether we should do any given thing).
Not a contributor, so take my opinion with a grain of salt…
This feels super hacky and inconsistent to me.
I’m a fairly sophisticated Linux user, but if I was new to Qubes this feature would confuse me as it seems really inconsistent.
Why does this template have no network access if I can arbitrarily download scripts by adding dash proxy to my command? Which commands can I proxy and which commands can I not? What are the devs trying to imply here?
If a user needs network access then they can just assign networking to the template.
Seeing as these can be created arbitrarily, and have differing trust levels, it seems like it should just be the decision of the user.
Your solution may work with minimal intervention in the case of installing Signal but about other instructions that connect to the internet in other ways? Say I need to build something from source, are we going to include git-proxy too?
If we’re optimizing for non tech-savvy users, then I think it’s much more reasonable to just include the GPG keys of well known apps.
If you’re installing software outside of this then you’re probably sophisticated enough to download a GPG key in VM A and copy it to VM B, infact I’d argue doing this is one of the main idioms of Qubes.
You say that you’re adverse to exposing the templates to the network for security reasons, but from my perspective this is in essence what you’re doing. Your hypothetical user that would blindly follow the Signal install instructions would also blindly follow this too. sudo wget-proxy -O - http://instructions.on.the.web.com/not_malicious.sh | bash
