Updates Proxy a security Risk?
153 views
Skip to first unread message
johny...@sigaint.org
Aug 12, 2016, 6:31:25 PM8/12/16
to qubes...@googlegroups.com
Greetings, Qubers.
Say you have a VM (e.g. "Banking only"), which has a NetVM of
sys-firewall, but for which you have disallowed or greatly restricted
networking, turned off DNS and ICMP, but left on "allow connection to
updates proxy."
As I understand it, this creates rules in sys-firewall to enforce that
policy, and allow forwards to the tinyproxy living in sys-net on port
8082.
-A FORWARD -s 10.137.2.25/32 -d 10.137.255.254/32 -p tcp -m tcp --dport
8082 -j ACCEPT
-A FORWARD -s 10.137.2.25/32 -j REJECT --reject-with icmp-host-prohibited
Good 'nuff.
However, there is nothing stopping such an AppVM (say, for example, it
were compromised) to making any connections it wants through that
10.137.255.254:8082 proxy, to call home, download malware, whatever. (So
my otherwise properly-configured "Banking Only" vm, that is configured to
only allow connectons to my bank, can actually contact that hacker site in
russia if some bad javascript or other compromise happened.)
I set such a VM, networking disabled or restricted to one or two sites, no
ICMP, no DNS, but updates allowed, and pointed Iceweasel's proxy to
10.137.255.254:8082 and was able to browse to my heart's content, even
totally bypassing sys-firewall, so it was potentially even *more* open
than if "allow network access except" were checked.
This seems like a bit of a potential security risk.
In general, I would recommend that updates *only* be allowed for Template
VM's. And even then a compromised template can call home freely during
the (hopefully brief) time it's running. (Also, I would generally
recommend turning off all other Networking for a Template, unless you do
need some non-update network configuration for an app, such as adding a
browser plugin; but that should generally be rare.)
(Also, Temporary OS updates are indeed handy in the AppVM's for testing or
one-off app runs, but leaving this checkbox on is just like turning
networking full-on for the AppVM. The user should at least be aware of
this fact. I wasn't.)
At the very least, the GUI should educate the user about this fact, and
maybe pop up a warning/confirmation page if the user tries to enable
update access for an AppVM.
While it's easy to work around by leaving that option off except on
Templates, it's a simple way for new users to unwittingly leave an AppVM
wide open. I'm thinking the update server access process might need to be
re-considered a bit.
I also think more visibility of the overall firewall setup/layout and
potential packet paths (as well as actual traffic) needs to be done
somehow. Perhaps sys-firewall needs something more akin to Shorewall.
(Checking for leaks, and running iptraf in sys-net was rather depressing;
more on that in another post.)
Thoughts?
(I worry a bit that the attitude of the Qubes developers is "oh well, if
you're compromised, you're screwed anyway, no sense adding more security."
See no-password sudo, for example. I disagree with that approach, and
think any reasonable and clean security measures that could be added,
should be added. If you completely give up on the machine to one level of
compromise, you might as well write your sensitive documents with rock on
cave walls, deep underground, lit by torchlight. Although the way I've
been aggressively hacked for years, it might just come to that :P "Pass
the red berries, I need to highlight a sentence.")
By the way, I intend all my comments as constructive or for discussion.
It's an awesome system, kudos to Joanna and the team. It's been my main
platform for a couple of weeks now, and I'm loving it, despite a few
glitches and some confusing bits. I hope to be able to contribute
something back to the process.
(Is that Debian Template manager a paid position? :) )
JJ
Say you have a VM (e.g. "Banking only"), which has a NetVM of
sys-firewall, but for which you have disallowed or greatly restricted
networking, turned off DNS and ICMP, but left on "allow connection to
updates proxy."
As I understand it, this creates rules in sys-firewall to enforce that
policy, and allow forwards to the tinyproxy living in sys-net on port
8082.
-A FORWARD -s 10.137.2.25/32 -d 10.137.255.254/32 -p tcp -m tcp --dport
8082 -j ACCEPT
-A FORWARD -s 10.137.2.25/32 -j REJECT --reject-with icmp-host-prohibited
Good 'nuff.
However, there is nothing stopping such an AppVM (say, for example, it
were compromised) to making any connections it wants through that
10.137.255.254:8082 proxy, to call home, download malware, whatever. (So
my otherwise properly-configured "Banking Only" vm, that is configured to
only allow connectons to my bank, can actually contact that hacker site in
russia if some bad javascript or other compromise happened.)
I set such a VM, networking disabled or restricted to one or two sites, no
ICMP, no DNS, but updates allowed, and pointed Iceweasel's proxy to
10.137.255.254:8082 and was able to browse to my heart's content, even
totally bypassing sys-firewall, so it was potentially even *more* open
than if "allow network access except" were checked.
This seems like a bit of a potential security risk.
In general, I would recommend that updates *only* be allowed for Template
VM's. And even then a compromised template can call home freely during
the (hopefully brief) time it's running. (Also, I would generally
recommend turning off all other Networking for a Template, unless you do
need some non-update network configuration for an app, such as adding a
browser plugin; but that should generally be rare.)
(Also, Temporary OS updates are indeed handy in the AppVM's for testing or
one-off app runs, but leaving this checkbox on is just like turning
networking full-on for the AppVM. The user should at least be aware of
this fact. I wasn't.)
At the very least, the GUI should educate the user about this fact, and
maybe pop up a warning/confirmation page if the user tries to enable
update access for an AppVM.
While it's easy to work around by leaving that option off except on
Templates, it's a simple way for new users to unwittingly leave an AppVM
wide open. I'm thinking the update server access process might need to be
re-considered a bit.
I also think more visibility of the overall firewall setup/layout and
potential packet paths (as well as actual traffic) needs to be done
somehow. Perhaps sys-firewall needs something more akin to Shorewall.
(Checking for leaks, and running iptraf in sys-net was rather depressing;
more on that in another post.)
Thoughts?
(I worry a bit that the attitude of the Qubes developers is "oh well, if
you're compromised, you're screwed anyway, no sense adding more security."
See no-password sudo, for example. I disagree with that approach, and
think any reasonable and clean security measures that could be added,
should be added. If you completely give up on the machine to one level of
compromise, you might as well write your sensitive documents with rock on
cave walls, deep underground, lit by torchlight. Although the way I've
been aggressively hacked for years, it might just come to that :P "Pass
the red berries, I need to highlight a sentence.")
By the way, I intend all my comments as constructive or for discussion.
It's an awesome system, kudos to Joanna and the team. It's been my main
platform for a couple of weeks now, and I'm loving it, despite a few
glitches and some confusing bits. I hope to be able to contribute
something back to the process.
(Is that Debian Template manager a paid position? :) )
JJ
Andrew David Wong
Aug 13, 2016, 3:16:44 AM8/13/16
to johny...@sigaint.org, qubes...@googlegroups.com, Michael Carbone
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016-08-12 15:31, johny...@sigaint.org wrote:
> Greetings, Qubers.
>
> Say you have a VM (e.g. "Banking only"), which has a NetVM of sys-firewall,
> but for which you have disallowed or greatly restricted networking, turned
> off DNS and ICMP, but left on "allow connection to updates proxy."
>
That box should be unchecked by default in AppVMs and checked by default in
TemplateVMs.
> As I understand it, this creates rules in sys-firewall to enforce that
> policy, and allow forwards to the tinyproxy living in sys-net on port
> 8082.
>
> -A FORWARD -s 10.137.2.25/32 -d 10.137.255.254/32 -p tcp -m tcp --dport
> 8082 -j ACCEPT -A FORWARD -s 10.137.2.25/32 -j REJECT --reject-with
> icmp-host-prohibited
>
> Good 'nuff.
>
> However, there is nothing stopping such an AppVM (say, for example, it were
> compromised) to making any connections it wants through that
> 10.137.255.254:8082 proxy, to call home, download malware, whatever. (So
> my otherwise properly-configured "Banking Only" vm, that is configured to
> only allow connectons to my bank, can actually contact that hacker site in
> russia if some bad javascript or other compromise happened.)
>
> I set such a VM, networking disabled or restricted to one or two sites, no
> ICMP, no DNS, but updates allowed, and pointed Iceweasel's proxy to
> 10.137.255.254:8082 and was able to browse to my heart's content, even
> totally bypassing sys-firewall, so it was potentially even *more* open than
> if "allow network access except" were checked.
>
> This seems like a bit of a potential security risk.
>
Indeed, this is why the box is unchecked in AppVMs by default. :)
> In general, I would recommend that updates *only* be allowed for Template
> VM's.
I don't think this would be a good idea. There are many times when it's
important to be able to update or install a package in an AppVM even though it
won't persist after restarting that AppVM (to check compatibility, for
temporary use, etc.).
> And even then a compromised template can call home freely during the
> (hopefully brief) time it's running.
Well, yes, but if a TemplateVM is compromised, then it can potentially phone
home even if you remove its NetVM, due to the existence of cooperative covert
channels.
> (Also, I would generally recommend turning off all other Networking for a
> Template, unless you do need some non-update network configuration for an
> app, such as adding a browser plugin; but that should generally be rare.)
>
Indeed, this is why the default setting in TemplateVMs is to allow access only
to the updates proxy.
> (Also, Temporary OS updates are indeed handy in the AppVM's for testing or
> one-off app runs, but leaving this checkbox on is just like turning
> networking full-on for the AppVM. The user should at least be aware of
> this fact. I wasn't.)
>
> At the very least, the GUI should educate the user about this fact, and
> maybe pop up a warning/confirmation page if the user tries to enable update
> access for an AppVM.
>
In principle, I think this is a good idea. In practice, however, there are
already so many more accessible ways for users to shoot themselves in the
feet, e.g., running programs in dom0 or TemplateVMs (except for intentional
initial configuration). Ideally, we'd have such warnings in *all* of those
cases. While this would qualify as one of those cases, it seems a bit less
dire and bit less likely to affect huge swaths of new users (especially given
the defaults). If that's right, then it might be better to prioritize our
warning implementation efforts on the most blatant and serious pitfalls first.
> While it's easy to work around by leaving that option off except on
> Templates, it's a simple way for new users to unwittingly leave an AppVM
> wide open. I'm thinking the update server access process might need to be
> re-considered a bit.
>
> I also think more visibility of the overall firewall setup/layout and
> potential packet paths (as well as actual traffic) needs to be done
> somehow. Perhaps sys-firewall needs something more akin to Shorewall.
> (Checking for leaks, and running iptraf in sys-net was rather depressing;
> more on that in another post.)
>
I think that might fall under this:
https://github.com/QubesOS/qubes-issues/issues/2135
(I've added a link to this thread in my comment on that issue.)
> Thoughts?
>
> (I worry a bit that the attitude of the Qubes developers is "oh well, if
> you're compromised, you're screwed anyway, no sense adding more security."
> See no-password sudo, for example.
I think the idea is more like: "Let's not bullshit our users. If some
purported security measure doesn't actually add any real security, then we're
not going to implement (or preserve) it and point to it as evidence of defense
in depth (because it's really not). By contrast, we welcome defense in depth
that actually works."
> I disagree with that approach, and think any reasonable and clean security
> measures that could be added, should be added. If you completely give up
> on the machine to one level of compromise, you might as well write your
> sensitive documents with rock on cave walls, deep underground, lit by
> torchlight. Although the way I've been aggressively hacked for years, it
> might just come to that :P "Pass the red berries, I need to highlight a
> sentence.")
>
> By the way, I intend all my comments as constructive or for discussion.
> It's an awesome system, kudos to Joanna and the team. It's been my main
> platform for a couple of weeks now, and I'm loving it, despite a few
> glitches and some confusing bits. I hope to be able to contribute
> something back to the process.
>
> (Is that Debian Template manager a paid position? :) )
>
I think that depends on the current funding situation (CCing Michael).
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXrslLAAoJENtN07w5UDAwV2cP/jWZVNsbganFUNCNO55NadD9
Axf6ZnFdhNNjAaf9ZuVk3L6eld6dHXz9I4fnXq2U55pxqiBkIJh5UyHjbF/XE8Bb
Ijl8Hd/zcNdL94xAjQkUShqPENaY85fVe096qPNlbaFbkYIiz/9CzZeZsUSjWEzA
p5PUnMiU07J2u6W9JmxB3pP7m3MGYqnLSd8xUzNGktyS7KARD32pGxlvI1xus973
hGM+L/zF9Ip5b9BInRPLEgw9/F/S3m+RQWag2E3/3L+uaiUNdh1T4wekewXNr0yq
lWPKyNzb9lrZ25RFhp4R+rcYAos149bk8ACYPSPQJSP9YGngeEKFBv2PvijDAJ5R
GOkorCISKBYouuIsQlHiyI/Ij8WFHXi33u/UanFH/JTwfL5bQ+3WoCNpEDun3U8S
5BZqZUsoCs4F3yiAwpUJFkUd15sUEpmnx43c1EdlrGPA1rZ0svg9aVUEGRU9Hup/
L/Op2He3IUQeSW82NjzFtJ4ZHEBPp60bDmJC0/i20mnKWKJnvFiuOgMWHLDetvZ3
gciKRj8KtsuaEqWaYad44X6Aq2zoQyb7mf7G8LCiJ2Y/Bi8BMP0kyAZbs5PE5eBU
8ypQsIzy642BiIkhx53fJKvGyqAfTgh8q9WU+w3aShYH5UX9vRiFW9itd3TnnLe9
DqyWknsWpVYbt8In3K1A
=/w0H
-----END PGP SIGNATURE-----
Hash: SHA512
On 2016-08-12 15:31, johny...@sigaint.org wrote:
> Greetings, Qubers.
>
> Say you have a VM (e.g. "Banking only"), which has a NetVM of sys-firewall,
> but for which you have disallowed or greatly restricted networking, turned
> off DNS and ICMP, but left on "allow connection to updates proxy."
>
TemplateVMs.
> As I understand it, this creates rules in sys-firewall to enforce that
> policy, and allow forwards to the tinyproxy living in sys-net on port
> 8082.
>
> -A FORWARD -s 10.137.2.25/32 -d 10.137.255.254/32 -p tcp -m tcp --dport
> 8082 -j ACCEPT -A FORWARD -s 10.137.2.25/32 -j REJECT --reject-with
> icmp-host-prohibited
>
> Good 'nuff.
>
> However, there is nothing stopping such an AppVM (say, for example, it were
> compromised) to making any connections it wants through that
> 10.137.255.254:8082 proxy, to call home, download malware, whatever. (So
> my otherwise properly-configured "Banking Only" vm, that is configured to
> only allow connectons to my bank, can actually contact that hacker site in
> russia if some bad javascript or other compromise happened.)
>
> I set such a VM, networking disabled or restricted to one or two sites, no
> ICMP, no DNS, but updates allowed, and pointed Iceweasel's proxy to
> 10.137.255.254:8082 and was able to browse to my heart's content, even
> totally bypassing sys-firewall, so it was potentially even *more* open than
> if "allow network access except" were checked.
>
> This seems like a bit of a potential security risk.
>
> In general, I would recommend that updates *only* be allowed for Template
> VM's.
important to be able to update or install a package in an AppVM even though it
won't persist after restarting that AppVM (to check compatibility, for
temporary use, etc.).
> And even then a compromised template can call home freely during the
> (hopefully brief) time it's running.
home even if you remove its NetVM, due to the existence of cooperative covert
channels.
> (Also, I would generally recommend turning off all other Networking for a
> Template, unless you do need some non-update network configuration for an
> app, such as adding a browser plugin; but that should generally be rare.)
>
to the updates proxy.
> (Also, Temporary OS updates are indeed handy in the AppVM's for testing or
> one-off app runs, but leaving this checkbox on is just like turning
> networking full-on for the AppVM. The user should at least be aware of
> this fact. I wasn't.)
>
> At the very least, the GUI should educate the user about this fact, and
> maybe pop up a warning/confirmation page if the user tries to enable update
> access for an AppVM.
>
already so many more accessible ways for users to shoot themselves in the
feet, e.g., running programs in dom0 or TemplateVMs (except for intentional
initial configuration). Ideally, we'd have such warnings in *all* of those
cases. While this would qualify as one of those cases, it seems a bit less
dire and bit less likely to affect huge swaths of new users (especially given
the defaults). If that's right, then it might be better to prioritize our
warning implementation efforts on the most blatant and serious pitfalls first.
> While it's easy to work around by leaving that option off except on
> Templates, it's a simple way for new users to unwittingly leave an AppVM
> wide open. I'm thinking the update server access process might need to be
> re-considered a bit.
>
> I also think more visibility of the overall firewall setup/layout and
> potential packet paths (as well as actual traffic) needs to be done
> somehow. Perhaps sys-firewall needs something more akin to Shorewall.
> (Checking for leaks, and running iptraf in sys-net was rather depressing;
> more on that in another post.)
>
https://github.com/QubesOS/qubes-issues/issues/2135
(I've added a link to this thread in my comment on that issue.)
> Thoughts?
>
> (I worry a bit that the attitude of the Qubes developers is "oh well, if
> you're compromised, you're screwed anyway, no sense adding more security."
> See no-password sudo, for example.
purported security measure doesn't actually add any real security, then we're
not going to implement (or preserve) it and point to it as evidence of defense
in depth (because it's really not). By contrast, we welcome defense in depth
that actually works."
> I disagree with that approach, and think any reasonable and clean security
> measures that could be added, should be added. If you completely give up
> on the machine to one level of compromise, you might as well write your
> sensitive documents with rock on cave walls, deep underground, lit by
> torchlight. Although the way I've been aggressively hacked for years, it
> might just come to that :P "Pass the red berries, I need to highlight a
> sentence.")
>
> By the way, I intend all my comments as constructive or for discussion.
> It's an awesome system, kudos to Joanna and the team. It's been my main
> platform for a couple of weeks now, and I'm loving it, despite a few
> glitches and some confusing bits. I hope to be able to contribute
> something back to the process.
>
> (Is that Debian Template manager a paid position? :) )
>
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXrslLAAoJENtN07w5UDAwV2cP/jWZVNsbganFUNCNO55NadD9
Axf6ZnFdhNNjAaf9ZuVk3L6eld6dHXz9I4fnXq2U55pxqiBkIJh5UyHjbF/XE8Bb
Ijl8Hd/zcNdL94xAjQkUShqPENaY85fVe096qPNlbaFbkYIiz/9CzZeZsUSjWEzA
p5PUnMiU07J2u6W9JmxB3pP7m3MGYqnLSd8xUzNGktyS7KARD32pGxlvI1xus973
hGM+L/zF9Ip5b9BInRPLEgw9/F/S3m+RQWag2E3/3L+uaiUNdh1T4wekewXNr0yq
lWPKyNzb9lrZ25RFhp4R+rcYAos149bk8ACYPSPQJSP9YGngeEKFBv2PvijDAJ5R
GOkorCISKBYouuIsQlHiyI/Ij8WFHXi33u/UanFH/JTwfL5bQ+3WoCNpEDun3U8S
5BZqZUsoCs4F3yiAwpUJFkUd15sUEpmnx43c1EdlrGPA1rZ0svg9aVUEGRU9Hup/
L/Op2He3IUQeSW82NjzFtJ4ZHEBPp60bDmJC0/i20mnKWKJnvFiuOgMWHLDetvZ3
gciKRj8KtsuaEqWaYad44X6Aq2zoQyb7mf7G8LCiJ2Y/Bi8BMP0kyAZbs5PE5eBU
8ypQsIzy642BiIkhx53fJKvGyqAfTgh8q9WU+w3aShYH5UX9vRiFW9itd3TnnLe9
DqyWknsWpVYbt8In3K1A
=/w0H
-----END PGP SIGNATURE-----
johny...@sigaint.org
Aug 13, 2016, 12:49:36 PM8/13/16
to Andrew David Wong, johny...@sigaint.org, qubes...@googlegroups.com, michael@invisiblethingslab
>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
>> sys-firewall,
>> but for which you have disallowed or greatly restricted networking,
>> turned
>> off DNS and ICMP, but left on "allow connection to updates proxy."
>>
>
> That box should be unchecked by default in AppVMs and checked by default
> in
> TemplateVMs.
Fair enough. Choosing a sane default is half the battle, and does indicate
>> sys-firewall,
>> but for which you have disallowed or greatly restricted networking,
>> turned
>> off DNS and ICMP, but left on "allow connection to updates proxy."
>>
>
> That box should be unchecked by default in AppVMs and checked by default
> in
> TemplateVMs.
to the user (subtly ;) ) the right thing to do. And I agree you don't
want to
"warn the user to death" about every possible peril.
One argument I might make, however, is that the update proxy does not belong
in the sys-net VM, but in the sys-firewall VM.
Part of the elegance of the sys-net VM is that it isolates the network card
from shenanigans affecting other parts of the system. Compromising the
update proxy could obviously hand over the "keys to the kingdom" to all
the VM's via template updates. (Although proper package signing and
verification
would limit that threat.)
And yes, if the network card is compromised, even moving the update proxy to
vm-firewall isn't going to protect you from mitm, redirection, DNS spoofing,
and other attacks from sys-network.
However, it does make more sense with yet-another suggestion I might make:
Since tinyproxy should only be used to contact legit update repos, there's no
reason it couldn't be configured (perhaps auto-configured by Qubes Manager,
from information in each template), to restrict access to *only* update sites
on port 443 (last part is already there). e.g.:
tinyproxy-updates.conf:
> FilterDefaultDeny YES
> Filter tinyproxy-updates-filter.conf
tinyproxy-updates-filter.conf:
> fedoraproject.org
> debian.net
> debian.org
> [windows URL for those crazy enough to run windows hvms...]
I'll be manually doing this myself, shortly.
I'll also try moving the update proxy to sys-firewall (just a matter of
setting it up there, and changing the Templates to have their dns/apt tools
to point to it, I think)... Where does the Qubes VM Manager get its
proxy-address to modify the firewall rules? Hopefully from some xml
template I can change.
With what I would now consider an important configuration file now
part of tinyproxy, it makes a bit more sense to get it out of sys-net,
so a compromised sys-net can't affect which servers the Template (or
mis-configured App) VM's are allowed to contact (although yes, it
could still redirect packets, yadda, yada, yadda...)
(Also, on a quick browse through the yum repos, did I see Adobe and
Google repos there? I'm not sure I inherently trust them. I'm
personally moving my system to be as Debian based as possible, to
remove U.S. and commercial companies from the mix as much as possible.)
>> (I worry a bit that the attitude of the Qubes developers is "oh well, if
>> you're compromised, you're screwed anyway, no sense adding more
>> security."
>> See no-password sudo, for example.
>
> I think the idea is more like: "Let's not bullshit our users. If some
> purported security measure doesn't actually add any real security, then
> we're
> not going to implement (or preserve) it and point to it as evidence of
> defense
> in depth (because it's really not). By contrast, we welcome defense in
> depth
> that actually works."
"well, that's sensible and up-front," which I like. :) And as long as
minds are open to discussions on how to improve things (being wary of
feature-creep), I'm very cool with it.
And hey, if I disagree with one of your policies, I'm free to change it on
my system. :)
JJ
Andrew David Wong
Aug 13, 2016, 1:54:31 PM8/13/16
to johny...@sigaint.org, qubes...@googlegroups.com, Marek Marczykowski-Górecki
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hash: SHA512
On 2016-08-13 09:49, johny...@sigaint.org wrote:
>>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
>>> sys-firewall, but for which you have disallowed or greatly restricted
>>> networking, turned off DNS and ICMP, but left on "allow connection to
>>> updates proxy."
>>>
>>
>> That box should be unchecked by default in AppVMs and checked by default
>> in TemplateVMs.
>
> Fair enough. Choosing a sane default is half the battle, and does
> indicate to the user (subtly ;) ) the right thing to do. And I agree you
> don't want to "warn the user to death" about every possible peril.
>
Perhaps a good compromise (i.e., a less intrusive way to warn/educate the user
>>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
>>> sys-firewall, but for which you have disallowed or greatly restricted
>>> networking, turned off DNS and ICMP, but left on "allow connection to
>>> updates proxy."
>>>
>>
>> That box should be unchecked by default in AppVMs and checked by default
>> in TemplateVMs.
>
> Fair enough. Choosing a sane default is half the battle, and does
> indicate to the user (subtly ;) ) the right thing to do. And I agree you
> don't want to "warn the user to death" about every possible peril.
>
about this) would be with an explanatory tooltip. Added the suggestion here:
https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632572
> One argument I might make, however, is that the update proxy does not
> belong in the sys-net VM, but in the sys-firewall VM.
>
> Part of the elegance of the sys-net VM is that it isolates the network
> card from shenanigans affecting other parts of the system. Compromising
> the update proxy could obviously hand over the "keys to the kingdom" to
> all the VM's via template updates. (Although proper package signing and
> verification would limit that threat.)
>
infrastructure" includes the updates servers. We basically assume those are
compromised and instead place our trust in package signature verification.
- From this perspective, it isn't handing over the keys to the kingdom at all,
and proper package signing and verification does more than just limit the
threat. It guarantees -- to the extent that cryptographic signatures can --
that the package we've received (even from a possibly compromised server) is
in fact the package the signer intended for us to receive.
> And yes, if the network card is compromised, even moving the update proxy
> to vm-firewall isn't going to protect you from mitm, redirection, DNS
> spoofing, and other attacks from sys-network.
>
> However, it does make more sense with yet-another suggestion I might make:
>
> Since tinyproxy should only be used to contact legit update repos, there's
> no reason it couldn't be configured (perhaps auto-configured by Qubes
> Manager, from information in each template), to restrict access to *only*
> update sites on port 443 (last part is already there). e.g.:
>
> tinyproxy-updates.conf:
>> FilterDefaultDeny YES Filter tinyproxy-updates-filter.conf
>
> tinyproxy-updates-filter.conf:
>> fedoraproject.org debian.net debian.org [windows URL for those crazy
>> enough to run windows hvms...]
>
> I'll be manually doing this myself, shortly.
>
> I'll also try moving the update proxy to sys-firewall (just a matter of
> setting it up there, and changing the Templates to have their dns/apt
> tools to point to it, I think)... Where does the Qubes VM Manager get its
> proxy-address to modify the firewall rules? Hopefully from some xml
> template I can change.
>
> With what I would now consider an important configuration file now part of
> tinyproxy, it makes a bit more sense to get it out of sys-net, so a
> compromised sys-net can't affect which servers the Template (or
> mis-configured App) VM's are allowed to contact (although yes, it could
> still redirect packets, yadda, yada, yadda...)
>
> (Also, on a quick browse through the yum repos, did I see Adobe and Google
> repos there? I'm not sure I inherently trust them. I'm personally moving
> my system to be as Debian based as possible, to remove U.S. and commercial
> companies from the mix as much as possible.)
>
we don't place any trust in those companies. The repos are just there for your
convenience, in case you want to enable them (e.g., in less trusted templates).
>>> (I worry a bit that the attitude of the Qubes developers is "oh well,
>>> if you're compromised, you're screwed anyway, no sense adding more
>>> security." See no-password sudo, for example.
>>
>> I think the idea is more like: "Let's not bullshit our users. If some
>> purported security measure doesn't actually add any real security, then
>> we're not going to implement (or preserve) it and point to it as evidence
>> of defense in depth (because it's really not). By contrast, we welcome
>> defense in depth that actually works."
>
> Again, fair enough. The first couple of times I saw that approach, I
> thought "well, that's sensible and up-front," which I like. :) And as
> long as minds are open to discussions on how to improve things (being wary
> of feature-creep), I'm very cool with it.
>
> And hey, if I disagree with one of your policies, I'm free to change it on
> my system. :)
>
> JJ
>
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXr17JAAoJENtN07w5UDAwO84P/2nLhREjZFwjGwsWB43R40zT
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
3A3WBGtpsomeoMKwtIzoW2JIYzbfnJ0v11pq4KrqGm0DfvSpT952MN1bVtV+bV2t
/pia5bU7NOUojJ98AflfGqjAWcZ9dVF59mjQUw37KMDo9/V9y5P39cizamQzDzIT
No5LMKNxaxwOzxsszMkGf/KY/UsRWIM8rcFUtoauug0QqNqz1Vht+Z5NMQNNFTBM
JfX69a12yKizfNdrNeW0msgafpkwR9QQUtuoISPkZQG0jtvs5g0S/+UpzW1mWyIF
bcYi6BkVvfKPbYEAtpFCtqvOTRsc9GHKEDczXVZyfbhhGPjcrepi0wZAq3nw4qJ6
43YLo6RevQxX7+krFbOShcQvqJBBRo08OQKZYfjUiMBt3oVL5sfwsXwotJ6O3vtt
hdoz+1KCWW+iR/nA2/5IWEeL+qZVeojAtcMUeB03wddb5nledMaHA55Ob1K/aJFt
fciRZYvD6c7JLb3ZZQakhF/59tC8C/PxGhXD9WyGpPt5UzRmE/tA5tN8rsPsZcDN
KoaVASUWk6dMrFiG9rj4TflNv0MUZE5xfoVwCupZ6Fv8DWPT8O4PShrfIw1M7OG8
HRS/aDG+jJp3gZFd/d4fJbF4NWv6W5iM7b3iWMt2QcnIGBhGqLJ17a0GboHqPGNc
b3J6fkJKhxNVVkOmyqUc
=LoJf
-----END PGP SIGNATURE-----
Marek Marczykowski-Górecki
Aug 13, 2016, 4:33:05 PM8/13/16
to Andrew David Wong, johny...@sigaint.org, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sat, Aug 13, 2016 at 10:54:22AM -0700, Andrew David Wong wrote:
> On 2016-08-13 09:49, johny...@sigaint.org wrote:
> >>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
> >>> sys-firewall, but for which you have disallowed or greatly restricted
> >>> networking, turned off DNS and ICMP, but left on "allow connection to
> >>> updates proxy."
> >>>
> >>
> >> That box should be unchecked by default in AppVMs and checked by default
> >> in TemplateVMs.
> >
> > Fair enough. Choosing a sane default is half the battle, and does
> > indicate to the user (subtly ;) ) the right thing to do. And I agree you
> > don't want to "warn the user to death" about every possible peril.
> >
>
> Perhaps a good compromise (i.e., a less intrusive way to warn/educate the user
> about this) would be with an explanatory tooltip. Added the suggestion here:
>
> https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632572
>
> > One argument I might make, however, is that the update proxy does not
> > belong in the sys-net VM, but in the sys-firewall VM.
> >
> > Part of the elegance of the sys-net VM is that it isolates the network
> > card from shenanigans affecting other parts of the system. Compromising
> > the update proxy could obviously hand over the "keys to the kingdom" to
> > all the VM's via template updates. (Although proper package signing and
> > verification would limit that threat.)
> >
>
> Part of the Qubes philosophy is "Don't trust the infrastructure," where "the
> infrastructure" includes the updates servers. We basically assume those are
> compromised and instead place our trust in package signature verification.
proxy, so all it can do, can also be done by any other component in the
network path between template and updates repository itself. This
includes anything running in sys-net (even if updates proxy is running
elsewhere).
> > And yes, if the network card is compromised, even moving the update proxy
> > to vm-firewall isn't going to protect you from mitm, redirection, DNS
> > spoofing, and other attacks from sys-network.
> >
> > However, it does make more sense with yet-another suggestion I might make:
> >
> > Since tinyproxy should only be used to contact legit update repos, there's
> > no reason it couldn't be configured (perhaps auto-configured by Qubes
> > Manager, from information in each template), to restrict access to *only*
> > update sites on port 443 (last part is already there). e.g.:
> >
> > tinyproxy-updates.conf:
> >> FilterDefaultDeny YES Filter tinyproxy-updates-filter.conf
> >
> > tinyproxy-updates-filter.conf:
> >> fedoraproject.org debian.net debian.org [windows URL for those crazy
> >> enough to run windows hvms...]
> >
> > I'll be manually doing this myself, shortly.
> >
> > I'll also try moving the update proxy to sys-firewall (just a matter of
> > setting it up there, and changing the Templates to have their dns/apt
> > tools to point to it, I think)... Where does the Qubes VM Manager get its
> > proxy-address to modify the firewall rules? Hopefully from some xml
> > template I can change.
In fact if you start updates proxy in sys-firewall, it will be enough -
it will intercept traffic going to the proxy. Details:
https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-9
> > With what I would now consider an important configuration file now part of
> > tinyproxy, it makes a bit more sense to get it out of sys-net, so a
> > compromised sys-net can't affect which servers the Template (or
> > mis-configured App) VM's are allowed to contact (although yes, it could
> > still redirect packets, yadda, yada, yadda...)
There is very little point in this. There is so much infrastructure
involved in updates distribution (all the mirrors etc), that assuming
none of it can be compromised is unrealistic. On the other hand, even
compromised mirror can't do anything about properly signed package
(besides hiding its existence).
Updates proxy is only to prevent user mistakes - like browsing the web
directly from the template. Its power comes not from filtering the
traffic, but from the fact that any application not explicitly
configured to use the proxy, will not be able to access the network.
By default only package managers are configured to use the proxy.
- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXr4P7AAoJENuP0xzK19csNqcH/1Fk/ZamkPmj4vA8cgdr7q/I
eidMIFnl8icmKEzdggOpMIjbLtdqTXfWkrea0R5+oF+qrvBzN+1P80rL6BVlNAeP
mb3YI0Fo2p+ZnNI3zsbx6aDo4DWBFbLmUcVzznHggHOfplfNJiA1agy8tMI1C92P
JLgZ7xepn8SIvTEoLJoI1lFEjOQPwGvrbohQUa3Wk5IuE7C7H8LVooVcJLnfX5Ne
Fl71nhyjxjt3lu9IYNkDd4B79JBc+SaazOObUIHEXfgcKeqBHYzC8bCGPGxzfWYa
aoXo9KTvjjDn9/i1Z22wk1Op0OFYz+tDY/l7HXQsFTxLc+crAuQCkX0K+pNEG+A=
=zimK
-----END PGP SIGNATURE-----
Hash: SHA256
On Sat, Aug 13, 2016 at 10:54:22AM -0700, Andrew David Wong wrote:
> On 2016-08-13 09:49, johny...@sigaint.org wrote:
> >>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
> >>> sys-firewall, but for which you have disallowed or greatly restricted
> >>> networking, turned off DNS and ICMP, but left on "allow connection to
> >>> updates proxy."
> >>>
> >>
> >> That box should be unchecked by default in AppVMs and checked by default
> >> in TemplateVMs.
> >
> > Fair enough. Choosing a sane default is half the battle, and does
> > indicate to the user (subtly ;) ) the right thing to do. And I agree you
> > don't want to "warn the user to death" about every possible peril.
> >
>
> Perhaps a good compromise (i.e., a less intrusive way to warn/educate the user
> about this) would be with an explanatory tooltip. Added the suggestion here:
>
> https://github.com/QubesOS/qubes-issues/issues/2211#issuecomment-239632572
>
> > One argument I might make, however, is that the update proxy does not
> > belong in the sys-net VM, but in the sys-firewall VM.
> >
> > Part of the elegance of the sys-net VM is that it isolates the network
> > card from shenanigans affecting other parts of the system. Compromising
> > the update proxy could obviously hand over the "keys to the kingdom" to
> > all the VM's via template updates. (Although proper package signing and
> > verification would limit that threat.)
> >
>
> Part of the Qubes philosophy is "Don't trust the infrastructure," where "the
> infrastructure" includes the updates servers. We basically assume those are
> compromised and instead place our trust in package signature verification.
> From this perspective, it isn't handing over the keys to the kingdom at all,
> and proper package signing and verification does more than just limit the
> threat. It guarantees -- to the extent that cryptographic signatures can --
> that the package we've received (even from a possibly compromised server) is
> in fact the package the signer intended for us to receive.
Exactly. Also note that the updates proxy is in fact a simple http
> and proper package signing and verification does more than just limit the
> threat. It guarantees -- to the extent that cryptographic signatures can --
> that the package we've received (even from a possibly compromised server) is
> in fact the package the signer intended for us to receive.
proxy, so all it can do, can also be done by any other component in the
network path between template and updates repository itself. This
includes anything running in sys-net (even if updates proxy is running
elsewhere).
> > And yes, if the network card is compromised, even moving the update proxy
> > to vm-firewall isn't going to protect you from mitm, redirection, DNS
> > spoofing, and other attacks from sys-network.
> >
> > However, it does make more sense with yet-another suggestion I might make:
> >
> > Since tinyproxy should only be used to contact legit update repos, there's
> > no reason it couldn't be configured (perhaps auto-configured by Qubes
> > Manager, from information in each template), to restrict access to *only*
> > update sites on port 443 (last part is already there). e.g.:
> >
> > tinyproxy-updates.conf:
> >> FilterDefaultDeny YES Filter tinyproxy-updates-filter.conf
> >
> > tinyproxy-updates-filter.conf:
> >> fedoraproject.org debian.net debian.org [windows URL for those crazy
> >> enough to run windows hvms...]
> >
> > I'll be manually doing this myself, shortly.
> >
> > I'll also try moving the update proxy to sys-firewall (just a matter of
> > setting it up there, and changing the Templates to have their dns/apt
> > tools to point to it, I think)... Where does the Qubes VM Manager get its
> > proxy-address to modify the firewall rules? Hopefully from some xml
> > template I can change.
it will intercept traffic going to the proxy. Details:
https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-9
> > With what I would now consider an important configuration file now part of
> > tinyproxy, it makes a bit more sense to get it out of sys-net, so a
> > compromised sys-net can't affect which servers the Template (or
> > mis-configured App) VM's are allowed to contact (although yes, it could
> > still redirect packets, yadda, yada, yadda...)
involved in updates distribution (all the mirrors etc), that assuming
none of it can be compromised is unrealistic. On the other hand, even
compromised mirror can't do anything about properly signed package
(besides hiding its existence).
Updates proxy is only to prevent user mistakes - like browsing the web
directly from the template. Its power comes not from filtering the
traffic, but from the fact that any application not explicitly
configured to use the proxy, will not be able to access the network.
By default only package managers are configured to use the proxy.
- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXr4P7AAoJENuP0xzK19csNqcH/1Fk/ZamkPmj4vA8cgdr7q/I
eidMIFnl8icmKEzdggOpMIjbLtdqTXfWkrea0R5+oF+qrvBzN+1P80rL6BVlNAeP
mb3YI0Fo2p+ZnNI3zsbx6aDo4DWBFbLmUcVzznHggHOfplfNJiA1agy8tMI1C92P
JLgZ7xepn8SIvTEoLJoI1lFEjOQPwGvrbohQUa3Wk5IuE7C7H8LVooVcJLnfX5Ne
Fl71nhyjxjt3lu9IYNkDd4B79JBc+SaazOObUIHEXfgcKeqBHYzC8bCGPGxzfWYa
aoXo9KTvjjDn9/i1Z22wk1Op0OFYz+tDY/l7HXQsFTxLc+crAuQCkX0K+pNEG+A=
=zimK
-----END PGP SIGNATURE-----
Michael Carbone
Aug 13, 2016, 5:15:11 PM8/13/16
to Andrew David Wong, johny...@sigaint.org, qubes...@googlegroups.com
Andrew David Wong:
--
Michael Carbone
Qubes OS | https://www.qubes-os.org
@QubesOS <https://www.twitter.com/QubesOS>
*new GPG fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4*
old GPG fingerprint: 2DBE 2014 E7B0 0730 303D 7AAB 99AB 0624 6EEB F5A8
> On 2016-08-12 15:31, johny...@sigaint.org wrote:
>> (Is that Debian Template manager a paid position? :) )
>
> I think that depends on the current funding situation (CCing Michael).
currently no, though funding is actively being sought for it.
>> (Is that Debian Template manager a paid position? :) )
>
> I think that depends on the current funding situation (CCing Michael).
--
Michael Carbone
Qubes OS | https://www.qubes-os.org
@QubesOS <https://www.twitter.com/QubesOS>
*new GPG fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4*
old GPG fingerprint: 2DBE 2014 E7B0 0730 303D 7AAB 99AB 0624 6EEB F5A8
Reply all
Reply to author
Forward
0 new messages