@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
We have a variety of distros. Each of them have plethora of repositories, making each distro to have literally tens of thousands of packages reviewed by their maintainers, making it in a sum of hundreds of thousands of packages.
So, 2 questions bother me the most:
Why would I need some package not in a repository then?
Why those āwidelyā or widely used packages, like Signal for example is, arenāt found not in a single official repository?
I must say that these questions signal red light alarms to meā¦
I donāt think other distro devs care so much of loosing users because of not including some package in official repository. They left the room of doing it so.
Think only of Gentoo and users pursuing its devs to provide with built packages their repositories? Do they care? And we have even Gentoo here!
User must learn classic wget or curl, or must learn to blindly copy paste those commands, and for different distros (trying those distros out of Qubes, or in it) she has to learn different package manager (or how to blindly follow them), and itās just the same with another ādistroā - Qubes. It just has itās specialties.
Or should we try to make Qubes looks like ājust any other distroā?
Then each time that script would call wget/curl, those calls would be intercepted and paused for 3 seconds, showing what is attempted to be downloaded, giving opportunity for the user to CTRL-C per console instructions and showing you what the script you run is attempting to download on your behalf.
No protection on the sudo call here, but safeguards to download stuff only from curl/proxy. Other methods used to download stuff from your script would fail as usual. That was my proposition to ease while educate users attemtping to follow software installation guides expected to work ā¢. Nowhere is that PoC claiming to protrct users from running a random bash script in template/dom0. The claim was to wrap around and give a chance to the user to stop downloads happening in random scripts.
The net effect is still the same proxy or not, weāre giving the user a way of downloading arbitrary scripts from the internet in the templates.
Now, if you want to justify that by saying itās a convenience vs security thing, thatās one thing, but I donāt buy that doing it through a proxy is any safer than just exposing the network directly.
The three second pause also seems really in-elegant to me too. Weāre giving no information that the user didnāt have before executing the command in the first place. What are we even saying here? āThis command might be safe or it it might not be?ā I thought the whole point of this endeavor was to optimize for the usability of a non-technical user, how are they going to know whether to wait three seconds or not?
Currently the templates have a really clear threat model in mind. Bad software in them can threaten the compartmentalization of Qubes. Therefore, we disallow network access pushing users to use the trusted repositories, which enforce signature checking etc.
The aim of this change to me, is to improve usability for our hypothetical non tech savvy journalist (to quote your other post) without breaking the above threat model. With that in mind, intercepting wget and curl seems too low level.
I think it would be much cleaner to just add the keys of the common software this user wants to install. Iām not sure I buy the āno personaā software argument, as it seems that this change has a very specific person in mind as it currently stands.
The best thing you could do for this type of user, is make it so they can install signal/wire/session et al without manually downloading and verifying keys through the standard package manager mechanism
If people are really adverse to this, then I think a cleaner approach would be to develop a mechanism to add GPG/repos to templates in a safe way. This is more intuitive to me because itās more explicit than blindly intercepting network commands and adding arbitrary pauses.
the upstream team is unlikely to attempt to feed all distributions
signal-desktop is 100% open source ā¦ so any volunteer could start feeding e.g. Debian
Personally I can see one argument for the signal team wanting everyone to use their repo: speed of rolling out updates in case of compromise. By them fully controlling every step, they control how long it takes until updates are available. This might be important one day.
The āGeneral Discussionā category does not have āsolutionsā. Only āUser Supportā topics do. Thatās because a discussion canāt have a āsolutionā, just points of view. In this particular case, if and what actions will be taken is entirely decided by the qubes core team and not through any discussion had in this forum. Imagine the mess Qubes OS would be otherwise!
And that is, having an organisation deploying those repos+gpg keys, or, having Qubes take side into deploying some repositories/not others.
For the other points, the only solution to your comments would be to remove the proxy in Templates (they are used and wrapped by dnf/apt today), which could be interpreted by security by obscurity. A script downloaded per other qube, pushed into templates calling wget/curl with proxy arguments would work as is, today.
