I dont like the Qubes update proxy freedom - how do I disable it being a way for TemplateVMs to arbitrarily access the internet?

User Support
1

A TemplateVM without a NetVM is not completely cut off from the Internet. Qubes OS exposes 127.0.0.1:8082 through qubes.UpdatesProxy, and any proxy-aware process can use it to access the internet - this is commonly used to install flatpaks, for example. But it gives me OCD, I only want templateVMs to be able to talk to my apt proxy and thats it.

My sys-gateway runs apt-cacher-ng with ordinary HTTP blocked, CONNECT disabled, SOAP forwarding disabled, redirects disabled, and upstream TLS verification enabled.

ForceManaged: 0
ForwardBtsSoap: 0
AllowUserPorts: 443
RedirMax: 0
PassThroughPattern: ^$
CApath: /etc/ssl/certs
NoSSLChecks: 0

Even with those restrictions, ForceManaged: 0 lets a process request an arbitrary URL using http://HTTPS///host/path, or send plaintext HTTP to port 443. The update proxy therefore still provides limited GET-based egress from an otherwise offline TemplateVM.

Is there a Qubes-native or apt-cacher-ng-supported way to permit package repositories without leaving this general-purpose path open?

My dumbest idea so far would be to enable ForceManaged: 1 and write a small helper that parses apt-cacher-ng’s rejection log, and then prompt the user if he wan’ts to accept thoes, and from those decisions create config files in acng so they only have to confirm/deny once. However this would mean that every first apt action inside a template would fail, which sucks.

I understand that I could list all “known” Debian repos here, but as this is for kuhbs, this enduser config management thing I’m working on, this isn’t realistic, as I can not possibly know every small custom debian repo the enduser might want to put into his “kuhb” (a definition on how to build Qubes OS VMs).

I could chain my gateway VM with apt-cacher-ng through my new Qubes-Snitch, a firewall that asks you live as traffic appears if you want to accept or deny it, but my network chain has the firewall BEFORE the gateway, like:

kuhbs-net-nic ← kuhbs-net-gateway (which also owns VPN) ← kuhbs-firewall ← application-vms

So not sure what to do here now.

Is there a Qubes way, or has anybody found a solution other than managing a strict list of repos, that lets me do this?

I can kinda answer my own question - from what I know this isn’t possible with acng nor with the qrexec service that the apt proxy mechanism uses… But asking is free, maybe you guys have an idea.

What I’d ultimately need would be sth like “only apt repo traffic allowed” or “interactively select allowed traffic” (the latter I could code myself, but the only viable solutions I see are ugly, and I don’t really want to cause I have enough complexity in kuhbs already).

Sidenote: it kinda doesn’t matter to much, as TemplateVMs are trusted and its HIGHLY unlikely that they will be compromised during setup, but the fact that they have no netvm and can still “surf the web” so to speak still gives me OCD lol.

2

I answered my own question…

I’m asking this for kuhbs, and I will put the apt-cacher-ng VM behind qubes-snitch, so that if it wants something (connect to a repo) the normal qubes-snitch can do its “do you want to allow this connection” thing. This way the user can decide that.

Kinda like this:

kuhbs-net-nic < kuhbs-net-vpn < (optional kuhbs-net-tor here) < kuhbs-net-firewall < kuhbs-net-cache
                                                                                   < appvm (browse, surf, thunderbird, signal, ...)

This way application vms (not AppVM, appvm for “application”) will use qubes updates-proxy (kuhbs-net-cache), which will route his acng stuff through firewall, which will prompt. I will have to adjust apt in the templateVMs a bit for timeout settings so the user has time to answer, but thats no big deal.

I’ll use this as solution, although this doesn’t solve the problem for anyone not using kuhbs (can’t help you guys there then, you may want to use pinned repos in acng, which I can’t, bcs I can’t know which repos users of kuhbs will configure themselves).

3

The answer is to set ForceManaged: 1 in acng.conf.
That limits use of the proxy to hosts defined as backends for repos
and therefore blocks other attempted use.

I dont understand your remark about “pinned repos”

You can also set the Qubes firewall to only access hosts defined in your
backend file on specified ports.

4

I meant ForceManaged, but my problem was that I can’t know what additional debian repos an enduser that uses kuhbs will want to configure. And asking an enduser “sure np, just add your repo to acng.conf” is bollocks.

You can also set the Qubes firewall to only access hosts defined in your
backend file on specified ports.

This is exactly the solution I went with now (in a nutshell) - I’m using Qubes-Snitch, so when a new repo is requested by the VM that runs acng, it will prompt the user to accept or deny this.

5

If the user is capable of installing a new repo, they are capable of
adding a line to acng.conf, particularly as they will likely have to
modify the URL.

If they are not, then you do it for them. I ship salt packages that will
add the new repo source, modify as needed depending on pillar for
cacher, and them modify cacher depending on whether ForceManaged is
enabled.
The pillars are created when the caching proxy is set up, so it’s
a simple couple of install states, and a template. Packaged in an
installable rpm. Simple enough.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

6

admin-level qubes os users will create “kuhb’s”, something like a “firefox kuhb” or a “signal kuhb” or similar. Signal for example uses a custom apt repo. Endusers will then add these git repos similar to how you add repositories, and then in the “App store” this will show up and you can click “install signal” (to put it simple).

As it is not predictable what apt repos users will add via kuhb repos they add, I was looking for a way to not just have acng talk to the world mode. Its a bit OCD, bcs templates are trusted anyways.

salt

I know, but kuhbs wont use salt (and I deeply dislike the salt of Qubes OS).

As a bit of context, a signal kuhb: my-kuhbs/signal at main · kuhbs/my-kuhbs · GitHub

These are created by more professional users (but its simple that somebody with a bit of IT knowledge can get it done too - maybe with help of AI).

Endusers then can click in the gui and add this: https://github.com/kuhbs/my-kuhbs whole thing as a “repository” (they “pin” a git commit hash in this case).

Its build in a way that an enduser can use it (if he cares enough about security, he will have to take that small hurdle).

7

OK, but I think you are reinventing the wheel.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.