Curl-proxy / wget-proxy scripts in Templates so users can add GPG distro keys linked to added external repositories

[Insurgo]

@adw

And it has to be “in ways they don’t understand,” because if they understood, they wouldn’t need these easy workarounds. The whole point of drop-in *-proxy replacements is to allow users to blindly follow terminal commands they find somewhere on the internet. But if that’s what they’re doing, then the resultant templates should be untrusted. But if the resultant templates are untrusted, then what’s the point of removing network access from them in order to “protect” them? Once a user decides to make a template untrusted, there is no sense is trying to prevent the user from doing untrusted things inside of it.

@adw Let’s go back to the idea of preventing network access to Templates for a minute. As per current deployed templates, user can install softwares that are included in defined and trusted repositories. Actual problem is to be able to deploy additional GPG public keys to verify signatures of packages for additional repositories. External trusted software repositories, with their own chain of trust and deployment signatures (authenticity, responsibility, integrity validation) is still the best and desired way of deploying softwares inside of Qubes OS.

Problem space

Qubes OS documentation, and contrib documentation, should not redo upstream software installation guides. Qubes OS should be able to provide a general solution, permitting to validate user expected (risky) choices, not permitting to do anything stupid in Templates, unless the user decides to shut down all the protections that were setuped to protect himself… against himself.

Proposed solution

1. The proposed solution (wget-proxy and curl-proxy, if implemented as is), would prevent a user from being able to simply copy paste wget and curl commands coming from any source, since those commands do not have any proxy defined.
2. The “alias” approach. Having aliases for wget pointing to wget-wrapper, and curl pointing to curl-wrapper, could intercept download attempts as @deeplow highlighted and explain to the user why that wget/curl call was intercepted, telling him to replace wget/curl with wget-proxy/curl-proxy. The wrapper could check if netvm is configured for the Template, and if not, warn the user of what he should do instead of calling those commands that cannot be used inside of a Template configured without network access for their protection.

Example

Combined, the end result could be, in the case of a user trying to install signal-desktop over debian-11:

• wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg

  • wget cannot dowload https://updates.signal.org/desktop/apt/keys.asc since Template is configured to not have internet. If you really intended to download that file, please replace wget by wget-proxy in past command line.

• wget-proxy -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg

Success.

Mitigation

• What we want here is to prevent users to download public key in another VM, copy the public key over the Template, move things around where the user already is puzzled by those simple, relatively truste, instructions (keep Signal example in mind).
• We want to prevent the user of bypassing the Template “no network” policy to follow standard external documentation.
• We want the user to be able to add additional repositories (No @demi GPG public keys packaging won’t help the whole solution here of users still needing to add external repositories, and following upstream instructions is a different problem them trying to prevent users of doing completely crazy stuff in a template @adw. Hopefully they clone it prior anyway, and if they want to give network access to that template, then as you said, that template should not be trusted anymore.
• We want the user to be able to learn what he does wrong and inform him of the security mechanisms in place. So if wget-wrapper and curl-wrapper are defined aliases, able to intercept wget and curl calls if there is no netvm, then telling him to replace his wget call by wget-proxy to download said file will make him understand what is happening, at least. And at best, will stop him from doing crazy stuff in a Template that has no netvm by default.

Makes sense?

@deeplow @adw:

@deeplow

On a completely different note, I might have cracked part of the difficulty of installing software in Qubes: (assuming it’s available on the repos, which is not the case of the previous discussion)

This will still need a solution for users to download and install legitimately Element, Signal, Session and VPN related repositories to say the least. And I do not think that re-documenting each software installation guide to interpret upstream instructions is the way to go. A user intending to install Signal trusts Signal maintainers and their distribution chain. I do not think that complicating UX without explaining to the end-user what is actually happening differently inside of a Template and what he should do about it, on a more general approach, is a good long-term approach.

@adw: I am not saying that wget should be wget-proxy here. I am saying that a user running random scripts will most probably call wget and curl directly, which should fail, but that commands simply failing is not enough to understand (current) where calling wget-proxy as an alias for wget would be disastrous (random, malicious code snippets would be able to download whatever). I’m saying we should tell the user that if the intended file is really intended to be downloaded (wget-wrapper ouput) then the user should just replace wget with wget-proxy

Edit: change the URLs since this discussion has been moved to its own thread.