Updates tinyproxy blocks HTTPS deb/rpm sites

[qubesuser]

Currently tinyproxy blocks all HTTPS sites except mirrors.fedoraproject.org, which means that some 3rd party update sites that use HTTPS don't work.

This is easily fixed by adding ^[^/]*:443$ to /etc/tinyproxy/filter-updates

This allows all HTTPS traffic through, but since the proxy needs to be explicitly configured it shouldn't be much of an issue. That could be solved by MITMing all SSL in the updates proxy and adding a custom certificate to all templates, but it doesn't seem worth it.

[marmarek]

@adrelanos, what do you think about allowing all HTTPS? Maybe not that bad idea?

[marmarek]

@adrelanos, what do you think about allowing all HTTPS? Maybe not that bad idea?

[adrelanos]

Maybe the proxy shouldn't do any filtering at all? Perhaps that would be simplest.

If we go by the following argument...

since the proxy needs to be explicitly configured it shouldn't be much of an issue

...then filter rules are superfluous.

[adrelanos]

Maybe the proxy shouldn't do any filtering at all? Perhaps that would be simplest.

If we go by the following argument...

since the proxy needs to be explicitly configured it shouldn't be much of an issue

...then filter rules are superfluous.

[marmarek]

Indeed, that might not be that bad.
Original reasoning: #568
It should work. @rootkovska anything against this?

[marmarek]

Indeed, that might not be that bad.
Original reasoning: #568
It should work. @rootkovska anything against this?

[rootkovska]

Allowing all https for the templates would allow the user to make an easy mistake and start browsing the web from the template, or am I misunderstanding the idea you're discussing?

[rootkovska]

Allowing all https for the templates would allow the user to make an easy mistake and start browsing the web from the template, or am I misunderstanding the idea you're discussing?

[adrelanos]

Without explicitly configuring the updates proxy - and only apt/apt is configured to do so - no network connections from the TemplateVM to external servers are possible.

For a user to start browsing the web from the TemplateVM, the user would have to explicitly configure using the updates proxy. Something that cannot happen by accident.

[adrelanos]

Without explicitly configuring the updates proxy - and only apt/apt is configured to do so - no network connections from the TemplateVM to external servers are possible.

For a user to start browsing the web from the TemplateVM, the user would have to explicitly configure using the updates proxy. Something that cannot happen by accident.

[rootkovska]

Ok, then perhaps this makes sense indeed.

[rootkovska]

Ok, then perhaps this makes sense indeed.

[adrelanos]

Also requires clean up /etc/tinyproxy/filter-updates:
https://github.com/marmarek/qubes-core-agent-linux/pull/49

Is something similar required for Fedora?

[adrelanos]

Also requires clean up /etc/tinyproxy/filter-updates:
https://github.com/marmarek/qubes-core-agent-linux/pull/49

Is something similar required for Fedora?

[unman]

@marmarek
@adrelanos
This looks like a huge mistake to me. @rootkovska 's instinct was correct.
What you've done is open another vector for compromise of any VM that uses the updates proxy, template or not. The fact that it requires configuration does not mean that it's only the VM user that can use it. It would be trivial to engineer an application or service that uses the (now open) proxy to route in and out from the VM.
imo the original justification in #568 for filtering still stands. It was another line of defence for VMs which has now been removed.
Please consider reverting this.

[unman]

@marmarek
@adrelanos
This looks like a huge mistake to me. @rootkovska 's instinct was correct.
What you've done is open another vector for compromise of any VM that uses the updates proxy, template or not. The fact that it requires configuration does not mean that it's only the VM user that can use it. It would be trivial to engineer an application or service that uses the (now open) proxy to route in and out from the VM.
imo the original justification in #568 for filtering still stands. It was another line of defence for VMs which has now been removed.
Please consider reverting this.

[rootkovska]

@unman but if we consider a malicious app gets to be executed (installed) in a template VMcube, then everything's lost already, right?

[rootkovska]

@unman but if we consider a malicious app gets to be executed (installed) in a template VMcube, then everything's lost already, right?

[adrelanos]

It would be trivial to engineer an application or service that uses the (now open) proxy to route in and out from the VM.

This is correct, but does not matter...

It was another line of defence for VMs which has now been removed.

The argument per-supposes the TemplateVM already being compromised. But if that is the case, we already lost. What would we win if malware from within a TemplateVM could not connect to the outside?

The argument also fails, because an attacker capable of engineering an application explicitly using the open proxy could also set up a server that passes the filter rules.

As per https://www.qubes-os.org/doc/software-update-vm/ chapter Updates proxy, it has always been only a usability feature preventing user errors, not a security feature.

If we'd go with the argument, the original request of this ticket would have to been declined. I.e. keep https forbidden by default. [Or going the MITMing all SSL route which sounds awful.]

[adrelanos]

It would be trivial to engineer an application or service that uses the (now open) proxy to route in and out from the VM.

This is correct, but does not matter...

It was another line of defence for VMs which has now been removed.

The argument per-supposes the TemplateVM already being compromised. But if that is the case, we already lost. What would we win if malware from within a TemplateVM could not connect to the outside?

The argument also fails, because an attacker capable of engineering an application explicitly using the open proxy could also set up a server that passes the filter rules.

As per https://www.qubes-os.org/doc/software-update-vm/ chapter Updates proxy, it has always been only a usability feature preventing user errors, not a security feature.

If we'd go with the argument, the original request of this ticket would have to been declined. I.e. keep https forbidden by default. [Or going the MITMing all SSL route which sounds awful.]

[marmarek]

Is something similar required for Fedora?

If file wasn't modified by the user, it will be cleaned automatically.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Is something similar required for Fedora?

If file wasn't modified by the user, it will be cleaned automatically.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[unman]

@adrelanos

As per https://www.qubes-os.org/doc/software-update-vm/ chapter Updates proxy, it has always been only a usability feature preventing user errors, not a security feature.

I have no idea what this means - of course it's a (limited) security feature. The original discussion and the page you cite make this clear. You might as well say that a firewall is a usability, not a security, feature.

If we'd go with the argument, the original request of this ticket would have to been declined. I.e. keep https forbidden by default. [Or going the MITMing all SSL route which sounds awful.]

Yes.
apt-cacher, which I use instead, uses mapping to circumvent the need for MITM. But there are workable mitm proxies.

The argument also fails, because an attacker capable of engineering an application explicitly using the open proxy could also set up a server that passes the filter rules.

Pretty bogus argument - the answer would be to tighten the filters, not dispense with them altogether.

I use the proxy setup for all sorts of cubes, not just templates. And no, just because a qube is compromised does NOT mean we are already lost. Think containment, egress filtering, etc.

@marmarek said in the list last time this was raised, "The only network accessible from template should be package repositories". I still think that's the case.This change is a mistake for anyone using tinyproxy.

[unman]

@adrelanos

As per https://www.qubes-os.org/doc/software-update-vm/ chapter Updates proxy, it has always been only a usability feature preventing user errors, not a security feature.

I have no idea what this means - of course it's a (limited) security feature. The original discussion and the page you cite make this clear. You might as well say that a firewall is a usability, not a security, feature.

If we'd go with the argument, the original request of this ticket would have to been declined. I.e. keep https forbidden by default. [Or going the MITMing all SSL route which sounds awful.]

Yes.
apt-cacher, which I use instead, uses mapping to circumvent the need for MITM. But there are workable mitm proxies.

The argument also fails, because an attacker capable of engineering an application explicitly using the open proxy could also set up a server that passes the filter rules.

Pretty bogus argument - the answer would be to tighten the filters, not dispense with them altogether.

I use the proxy setup for all sorts of cubes, not just templates. And no, just because a qube is compromised does NOT mean we are already lost. Think containment, egress filtering, etc.

@marmarek said in the list last time this was raised, "The only network accessible from template should be package repositories". I still think that's the case.This change is a mistake for anyone using tinyproxy.

[adrelanos]

unman:

Pretty bogus argument - the answer would be to tighten the filters, not dispense with them altogether.

This fails by design. Like antivirus. Always an imperfect system. Data
can always be load - by using a deb as container. And data can also
always be in - for example by using Morse. And there are a lot more
creative ways to circumvent such filtering.

If you want some antivirus alike filtering that is okay. But I don't
think Qubes should attempt to develop it and deploy it by default.

[adrelanos]

unman:

Pretty bogus argument - the answer would be to tighten the filters, not dispense with them altogether.

This fails by design. Like antivirus. Always an imperfect system. Data
can always be load - by using a deb as container. And data can also
always be in - for example by using Morse. And there are a lot more
creative ways to circumvent such filtering.

If you want some antivirus alike filtering that is okay. But I don't
think Qubes should attempt to develop it and deploy it by default.

[marmarek]

On Tue, Nov 17, 2015 at 04:32:47PM -0800, Patrick Schleizer wrote:

If you want some antivirus alike filtering that is okay. But I don't
think Qubes should attempt to develop it and deploy it by default.

Yes, exactly. We're talking here about default settings, which should be
secure enough, but also usable. Having just a proxy, which allows any
traffic meets those requirements, because:

1. It protects against user errors - like browsing internet in TemplateVM -
   this mechanism is about nothing more.
2. It allows you to setup any repository you like (http and https). And
   actually the same proxy can be used for other repository types
   (archlinux?)

In any case, you can freely modify the configuration on your system. You
can edit tinyproxy configuration, apply your own rules etc.

We're also working on management stack (based on salt) for ease some
customization - so it would be easier to get desired configuration in
all the templates. You can also check some threads on qubes-devel about
ansible - another management stack.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Tue, Nov 17, 2015 at 04:32:47PM -0800, Patrick Schleizer wrote:

If you want some antivirus alike filtering that is okay. But I don't
think Qubes should attempt to develop it and deploy it by default.

Yes, exactly. We're talking here about default settings, which should be
secure enough, but also usable. Having just a proxy, which allows any
traffic meets those requirements, because:

1. It protects against user errors - like browsing internet in TemplateVM -
   this mechanism is about nothing more.
2. It allows you to setup any repository you like (http and https). And
   actually the same proxy can be used for other repository types
   (archlinux?)

In any case, you can freely modify the configuration on your system. You
can edit tinyproxy configuration, apply your own rules etc.

We're also working on management stack (based on salt) for ease some
customization - so it would be easier to get desired configuration in
all the templates. You can also check some threads on qubes-devel about
ansible - another management stack.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?