Debian template by default bundles (and starts) Tor

[ReigoHein]

Hello

The official Qubes 3.1 RC 2 install provided me two additional install options, debian 8 and Whonix. I selected Debian 8 but deselected Whonix.

I noticed Tor activity on my network and discovered Qubes Debian template, by default, runs Tor. Now this might be okay for some users but for enterprise and other monitored networks, running Tor can actually be a very bad idea for the unknowing user.

I propose Tor service should only be enabled or even exist if Whonix is selected.

[adrelanos]

Has this bug been confirmed yet? Is an analysis of this issue still required? @marmarek (Asking, because if required I'll be asking the user more questions and investigate.)

[adrelanos]

Has this bug been confirmed yet? Is an analysis of this issue still required? @marmarek (Asking, because if required I'll be asking the user more questions and investigate.)

[marmarek]

Haven't checked that yet.

[marmarek]

Haven't checked that yet.

[adrelanos]

@desertstorm Are you sure this happens with the default unmodified Debian 8 template?

Can you show the output please what happens when you run

sudo apt-get remove tor

You don't need to say yes. Can say no. Never mind. The purpose is finding out if you have some package installed that depends on Tor.

[adrelanos]

@desertstorm Are you sure this happens with the default unmodified Debian 8 template?

Can you show the output please what happens when you run

sudo apt-get remove tor

You don't need to say yes. Can say no. Never mind. The purpose is finding out if you have some package installed that depends on Tor.

[adrelanos]

No need. @desertstorm

Issue confirmed.

[adrelanos]

No need. @desertstorm

Issue confirmed.

[adrelanos]

Issue understood. Analysis coming soon.

[adrelanos]

Issue understood. Analysis coming soon.

[adrelanos]

TLDR:
Can you revert please marmarek/qubes-builder-debian#24? @marmarek

---

Long:
marmarek/qubes-builder-debian#24 (by me) introduced this. apt-transport-tor depends on tor. We should revert it and would have almost zero disadvantages because it was based on flawed reasoning to begin with.

The following would not work.. But never mind...

deb     tor+http://<long string>.onion/debian unstable main

Since the following - update through .onion repositories - will still work (tested) behind a (transparent) Tor ProxyVM such as Whonix...

deb     http://<long string>.onion/debian unstable main

Do you foresee the qrexec-based network proxy (#806) to break this?

There is no reason to have apt-transport-tor installed in a TemplateVM. The only reason would be if someone wanted to update through .onion repositories but not wanting to use a (transparent) Tor ProxyVM such as Whonix. I would argue, that this is a flawed reason. The TemplateVM should not run it's own Tor client, because that is very difficult to do right. (/var/lib/tor sharing as explained below.) Also the security improvement qrexec-based network proxy (#806) goes into the opposite direction. Less stuff (not even TCP) running inside the TemplateVM. So introducing a running Tor client in the TemplateVM seems totally wrong.

---

A related issue is, that having the tor package installed results in running Tor inside TemplateVMs. And creates Tor's data dir /var/lib/tor, which should not be shared among TemplateBasedVMs. And TemplateBasedVMs would require a persistent /var/lib/tor (Tor entry guards...). [Btw Qubes-Whonix keeps care of all of that.] This is not just an issue with the tor package, but with any package that generates key/data/w/e in the root image. (example: perhaps openssh-server) Do we have a general ticket for that already?

---

Related:
#1159

[adrelanos]

TLDR:
Can you revert please marmarek/qubes-builder-debian#24? @marmarek

---

Long:
marmarek/qubes-builder-debian#24 (by me) introduced this. apt-transport-tor depends on tor. We should revert it and would have almost zero disadvantages because it was based on flawed reasoning to begin with.

The following would not work.. But never mind...

deb     tor+http://<long string>.onion/debian unstable main

Since the following - update through .onion repositories - will still work (tested) behind a (transparent) Tor ProxyVM such as Whonix...

deb     http://<long string>.onion/debian unstable main

Do you foresee the qrexec-based network proxy (#806) to break this?

There is no reason to have apt-transport-tor installed in a TemplateVM. The only reason would be if someone wanted to update through .onion repositories but not wanting to use a (transparent) Tor ProxyVM such as Whonix. I would argue, that this is a flawed reason. The TemplateVM should not run it's own Tor client, because that is very difficult to do right. (/var/lib/tor sharing as explained below.) Also the security improvement qrexec-based network proxy (#806) goes into the opposite direction. Less stuff (not even TCP) running inside the TemplateVM. So introducing a running Tor client in the TemplateVM seems totally wrong.

---

A related issue is, that having the tor package installed results in running Tor inside TemplateVMs. And creates Tor's data dir /var/lib/tor, which should not be shared among TemplateBasedVMs. And TemplateBasedVMs would require a persistent /var/lib/tor (Tor entry guards...). [Btw Qubes-Whonix keeps care of all of that.] This is not just an issue with the tor package, but with any package that generates key/data/w/e in the root image. (example: perhaps openssh-server) Do we have a general ticket for that already?

---

Related:
#1159

[marmarek]

Can you revert please marmarek/qubes-builder-debian#24? @marmarek

Done. Do we want some countermeasures for existing installations (like disabling the service from somewhere)? Or simply do not include it in next rc/final release?

Do you foresee the qrexec-based network proxy (#806) to break this?

As long as that proxy will have tor access (be a Whonix-gateway? or at least behind it) it should still work.

A related issue is, that having the tor package installed results in running Tor inside TemplateVMs. And creates Tor's data dir /var/lib/tor, which should not be shared among TemplateBasedVMs. And TemplateBasedVMs would require a persistent /var/lib/tor (Tor entry guards...). [Btw Qubes-Whonix keeps care of all of that.]

qubes-tor (aka TorVM) too. And also disables original tor service.

This is not just an issue with the tor package, but with any package that generates key/data/w/e in the root image. (example: perhaps openssh-server) Do we have a general ticket for that already?

Related to #1311
Generally we're trying to not start any unneeded services in templates and AppVMs. We have a long preset list for it here:
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/75-qubes-vm.preset
And a lot of drop-ins files with ConditionPathExists=/var/lib/qubes-service/something. This way service is started only when explicitly requested by the user. https://github.com/marmarek/qubes-core-agent-linux/pull/58 is a solution for handling such services data in somehow generic way.

[marmarek]

Can you revert please marmarek/qubes-builder-debian#24? @marmarek

Done. Do we want some countermeasures for existing installations (like disabling the service from somewhere)? Or simply do not include it in next rc/final release?

Do you foresee the qrexec-based network proxy (#806) to break this?

As long as that proxy will have tor access (be a Whonix-gateway? or at least behind it) it should still work.

A related issue is, that having the tor package installed results in running Tor inside TemplateVMs. And creates Tor's data dir /var/lib/tor, which should not be shared among TemplateBasedVMs. And TemplateBasedVMs would require a persistent /var/lib/tor (Tor entry guards...). [Btw Qubes-Whonix keeps care of all of that.]

qubes-tor (aka TorVM) too. And also disables original tor service.

This is not just an issue with the tor package, but with any package that generates key/data/w/e in the root image. (example: perhaps openssh-server) Do we have a general ticket for that already?

Related to #1311
Generally we're trying to not start any unneeded services in templates and AppVMs. We have a long preset list for it here:
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/75-qubes-vm.preset
And a lot of drop-ins files with ConditionPathExists=/var/lib/qubes-service/something. This way service is started only when explicitly requested by the user. https://github.com/marmarek/qubes-core-agent-linux/pull/58 is a solution for handling such services data in somehow generic way.

[adrelanos]

Do we want some countermeasures for existing installations (like disabling the service from somewhere)?

https://github.com/marmarek/qubes-core-agent-linux/pull/60

[adrelanos]

Do we want some countermeasures for existing installations (like disabling the service from somewhere)?

https://github.com/marmarek/qubes-core-agent-linux/pull/60

[marmarek]

marmarek/qubes-core-agent-linux#60

I think this should apply also to AppVMs based on default Debian template. And DispVMs etc. Generally tor shouldn't be started unless explicitly requested.

[marmarek]

marmarek/qubes-core-agent-linux#60

I think this should apply also to AppVMs based on default Debian template. And DispVMs etc. Generally tor shouldn't be started unless explicitly requested.

[adrelanos]

Marek Marczykowski-Górecki:

marmarek/qubes-core-agent-linux#60

I think this should apply also to AppVMs based on default Debian template. And DispVMs etc. Generally tor shouldn't be started unless explicitly requested.

This is a bigger discussion. And bigger development effort. For example,
we would have to express in systemd something like "generally don't
start in VMs, but also not break whonix-gw / qubes-tor based ProxyVMs"
(these would not have the required state file created).

marmarek/qubes-core-agent-linux#60 should be mergeable as quick fix and
the other one deserves it's own ticket?

[adrelanos]

Marek Marczykowski-Górecki:

marmarek/qubes-core-agent-linux#60

I think this should apply also to AppVMs based on default Debian template. And DispVMs etc. Generally tor shouldn't be started unless explicitly requested.

This is a bigger discussion. And bigger development effort. For example,
we would have to express in systemd something like "generally don't
start in VMs, but also not break whonix-gw / qubes-tor based ProxyVMs"
(these would not have the required state file created).

marmarek/qubes-core-agent-linux#60 should be mergeable as quick fix and
the other one deserves it's own ticket?

[marmarek]

Actually running tor in TemplateVM in default setup probably is only little waste of resources, but nothing more. Thanks to default firewall policy which is "deny". So it will not reach the network.

This is a bigger discussion. And bigger development effort. For example, we would have to express in systemd something like "generally don't start in VMs, but also not break whonix-gw / qubes-tor based ProxyVMs" (these would not have the required state file created).

I wouldn't care about qubes-tor, because it has its own service and explicitly disable the default one.

But don't know about whonix-gw - is it using that default systemd service?

[marmarek]

Actually running tor in TemplateVM in default setup probably is only little waste of resources, but nothing more. Thanks to default firewall policy which is "deny". So it will not reach the network.

This is a bigger discussion. And bigger development effort. For example, we would have to express in systemd something like "generally don't start in VMs, but also not break whonix-gw / qubes-tor based ProxyVMs" (these would not have the required state file created).

I wouldn't care about qubes-tor, because it has its own service and explicitly disable the default one.

But don't know about whonix-gw - is it using that default systemd service?

[adrelanos]

Marek Marczykowski-Górecki:

But don't know about whonix-gw - is it using that default systemd service?

As of Whonix 12, yes. An "only-start-tor-if-this-status-file-exists"
would break it.

[adrelanos]

Marek Marczykowski-Górecki:

But don't know about whonix-gw - is it using that default systemd service?

As of Whonix 12, yes. An "only-start-tor-if-this-status-file-exists"
would break it.

[marmarek]

Maybe "this-status-file-exists" should be "/var/lib/whonix"? Or better:

ConditionPathExists=|/var/lib/whonix
ConditionPathExists=|/var/run/qubes-service/tor

So the service will be started if any of those exists. Is it ok?

[marmarek]

Maybe "this-status-file-exists" should be "/var/lib/whonix"? Or better:

ConditionPathExists=|/var/lib/whonix
ConditionPathExists=|/var/run/qubes-service/tor

So the service will be started if any of those exists. Is it ok?

[adrelanos]

Marek Marczykowski-Górecki:

Maybe "this-status-file-exists" should be "/var/lib/whonix"? Or better:

ConditionPathExists=|/var/lib/whonix

/var/lib/whonix would also exists in Whonix TemplateVMs. So not good.

(Btw, there would be a more suited marker file:
/usr/share/anon-gw-base-files/gateway)

/var/run/qubes-service/whonix-gateway as status file would work. (Even
though I wanted to get rid of these and replacing them with something
Qubes native.)

[adrelanos]

Marek Marczykowski-Górecki:

Maybe "this-status-file-exists" should be "/var/lib/whonix"? Or better:

ConditionPathExists=|/var/lib/whonix

/var/lib/whonix would also exists in Whonix TemplateVMs. So not good.

(Btw, there would be a more suited marker file:
/usr/share/anon-gw-base-files/gateway)

/var/run/qubes-service/whonix-gateway as status file would work. (Even
though I wanted to get rid of these and replacing them with something
Qubes native.)

[ReigoHein]

The original problem was that Tor was being automatically executed inside an AppVM which on monitored networks is a horrible idea. In order to be enterprise-friendly, it should only be enabled if the user explicitly selects Whonix addons.

[ReigoHein]

The original problem was that Tor was being automatically executed inside an AppVM which on monitored networks is a horrible idea. In order to be enterprise-friendly, it should only be enabled if the user explicitly selects Whonix addons.

[adrelanos]

The original problem was that Tor was being automatically executed inside an AppVM which on monitored networks is a horrible idea.

And that is sorted out in next RC.

[adrelanos]

The original problem was that Tor was being automatically executed inside an AppVM which on monitored networks is a horrible idea.

And that is sorted out in next RC.

[marmarek]

And that is sorted out in next RC.

Unless someone is updating instead of reinstalling...

[marmarek]

And that is sorted out in next RC.

Unless someone is updating instead of reinstalling...

[adrelanos]

Marek Marczykowski-Górecki:

And that is sorted out in next RC.

Unless someone is updating instead of reinstalling...

Indeed. However kinda difficult to fix. Would it be sufficient to note
in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

[adrelanos]

Marek Marczykowski-Górecki:

And that is sorted out in next RC.

Unless someone is updating instead of reinstalling...

Indeed. However kinda difficult to fix. Would it be sufficient to note
in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

[marmarek]

Would it be sufficient to note in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

It may be an option. But there is also another question - if someone installs tor in debian template on purpose, should it be really started in all the VMs by default?

[marmarek]

Would it be sufficient to note in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

It may be an option. But there is also another question - if someone installs tor in debian template on purpose, should it be really started in all the VMs by default?

[adrelanos]

Marek Marczykowski-Górecki:

Would it be sufficient to note in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

It may be an option. But there is also another question - if someone installs tor in debian template on purpose, should it be really started in all the VMs by default?

It's a really good question that applies to more packages than just Tor.

To require the user to create a qvm-service file, i.e. to

vm settings -> services -> type 'tor' press enter -> press 'plus'

isn't obvious at all. Would require documentation. Would be a usability
issue.

However, you really have a point here. Should I open a discussion on
qubes-devel to start some brain storming? openssh-server would share the
/etc/ssh keys. Do you have another great example to illustrate this issue?

And I guess we don't have the resources to greatly rework qvm-service
framework so it would come with pre-existing but unselected defaults for
tor, openssh-server and others, which would be once checked,
automatically installed in the TemplateVM and then activated in the
selected TemplateBasedVM. [seems like too much implementation effort to
me before 4.0 or w/e)]

The wider Debian upstream problem here is that Debian enables services
for installed packages by default; and that these packages/services are
not 'Qubes aware', not 'Qubes friendly' or perhaps better more
generically speaking not 'root image sharing friendly'. [open for better
terminology]

Perhaps a drastic solution would be required. Configure somehow that all
installed packages will not start their services by default. Only start
services on a whitelist / opt-in basis. This is not thought through. I
guess this could lead to some issues. And also confusion. But then the
documentation and implementation could be a lot more generic.

[adrelanos]

Marek Marczykowski-Górecki:

Would it be sufficient to note in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

It may be an option. But there is also another question - if someone installs tor in debian template on purpose, should it be really started in all the VMs by default?

It's a really good question that applies to more packages than just Tor.

To require the user to create a qvm-service file, i.e. to

vm settings -> services -> type 'tor' press enter -> press 'plus'

isn't obvious at all. Would require documentation. Would be a usability
issue.

However, you really have a point here. Should I open a discussion on
qubes-devel to start some brain storming? openssh-server would share the
/etc/ssh keys. Do you have another great example to illustrate this issue?

And I guess we don't have the resources to greatly rework qvm-service
framework so it would come with pre-existing but unselected defaults for
tor, openssh-server and others, which would be once checked,
automatically installed in the TemplateVM and then activated in the
selected TemplateBasedVM. [seems like too much implementation effort to
me before 4.0 or w/e)]

The wider Debian upstream problem here is that Debian enables services
for installed packages by default; and that these packages/services are
not 'Qubes aware', not 'Qubes friendly' or perhaps better more
generically speaking not 'root image sharing friendly'. [open for better
terminology]

Perhaps a drastic solution would be required. Configure somehow that all
installed packages will not start their services by default. Only start
services on a whitelist / opt-in basis. This is not thought through. I
guess this could lead to some issues. And also confusion. But then the
documentation and implementation could be a lot more generic.

[marmarek]

On Tue, Jan 19, 2016 at 01:57:47PM -0800, Patrick Schleizer wrote:

Marek Marczykowski-Górecki:

Would it be sufficient to note in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

It may be an option. But there is also another question - if someone installs tor in debian template on purpose, should it be really started in all the VMs by default?

It's a really good question that applies to more packages than just Tor.

Yes.

To require the user to create a qvm-service file, i.e. to

vm settings -> services -> type 'tor' press enter -> press 'plus'

isn't obvious at all. Would require documentation. Would be a usability
issue.

Agree.

However, you really have a point here. Should I open a discussion on
qubes-devel to start some brain storming?

Yes, good idea.

openssh-server would share the
/etc/ssh keys. Do you have another great example to illustrate this issue?

I think there are three types of services that may have sense to not start
by default (in every VM):

• those generating some sensitive (=not intended to be shared) data
  (tor, ssh server, some database servers?)
• those generating potentially unwanted/unexpected network traffic
  (tor, IPv6 tunneling software, VPN services, avahi, ...)
• generally unneeded services in most VMs - just for saving resources
  (RAM, at least) - like bluetoothd, crond, upowerd, smartd, acpid, ...
  not all of them are easily removable, because of dependencies

As for the second category, it isn't only about potentially harmful
actions (like connecting to tor directly, in some censored regions), but
also about wasting network resources - especially important on mobile
connection.

And I guess we don't have the resources to greatly rework qvm-service
framework so it would come with pre-existing but unselected defaults for
tor, openssh-server and others, which would be once checked,
automatically installed in the TemplateVM and then activated in the
selected TemplateBasedVM. [seems like too much implementation effort to
me before 4.0 or w/e)]

Yes. But we may introduce some useful base API for that in 4.0:
#1637

Having that API it would be somehow easier to implement such
functionality as a plugin.

The wider Debian upstream problem here is that Debian enables services
for installed packages by default; and that these packages/services are
not 'Qubes aware', not 'Qubes friendly' or perhaps better more
generically speaking not 'root image sharing friendly'. [open for better
terminology]

As said above - root image sharing is not the only reason for not
starting service.

Perhaps a drastic solution would be required. Configure somehow that all
installed packages will not start their services by default. Only start
services on a whitelist / opt-in basis. This is not thought through. I
guess this could lead to some issues. And also confusion. But then the
documentation and implementation could be a lot more generic.

I'm thinking of something like this as a generic solution here. I guess
it would be really simple to implement using systemd preset file.

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, Jan 19, 2016 at 01:57:47PM -0800, Patrick Schleizer wrote:

Marek Marczykowski-Górecki:

Would it be sufficient to note in the upgrade notes to recommend "sudo apt-get purge apt-transport-tor"?

It may be an option. But there is also another question - if someone installs tor in debian template on purpose, should it be really started in all the VMs by default?

It's a really good question that applies to more packages than just Tor.

Yes.

To require the user to create a qvm-service file, i.e. to

vm settings -> services -> type 'tor' press enter -> press 'plus'

isn't obvious at all. Would require documentation. Would be a usability
issue.

Agree.

However, you really have a point here. Should I open a discussion on
qubes-devel to start some brain storming?

Yes, good idea.

openssh-server would share the
/etc/ssh keys. Do you have another great example to illustrate this issue?

I think there are three types of services that may have sense to not start
by default (in every VM):

• those generating some sensitive (=not intended to be shared) data
  (tor, ssh server, some database servers?)
• those generating potentially unwanted/unexpected network traffic
  (tor, IPv6 tunneling software, VPN services, avahi, ...)
• generally unneeded services in most VMs - just for saving resources
  (RAM, at least) - like bluetoothd, crond, upowerd, smartd, acpid, ...
  not all of them are easily removable, because of dependencies

As for the second category, it isn't only about potentially harmful
actions (like connecting to tor directly, in some censored regions), but
also about wasting network resources - especially important on mobile
connection.

And I guess we don't have the resources to greatly rework qvm-service
framework so it would come with pre-existing but unselected defaults for
tor, openssh-server and others, which would be once checked,
automatically installed in the TemplateVM and then activated in the
selected TemplateBasedVM. [seems like too much implementation effort to
me before 4.0 or w/e)]

Yes. But we may introduce some useful base API for that in 4.0:
#1637

Having that API it would be somehow easier to implement such
functionality as a plugin.

The wider Debian upstream problem here is that Debian enables services
for installed packages by default; and that these packages/services are
not 'Qubes aware', not 'Qubes friendly' or perhaps better more
generically speaking not 'root image sharing friendly'. [open for better
terminology]

As said above - root image sharing is not the only reason for not
starting service.

Perhaps a drastic solution would be required. Configure somehow that all
installed packages will not start their services by default. Only start
services on a whitelist / opt-in basis. This is not thought through. I
guess this could lead to some issues. And also confusion. But then the
documentation and implementation could be a lot more generic.

I'm thinking of something like this as a generic solution here. I guess
it would be really simple to implement using systemd preset file.

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?

[adrelanos]

How to get rid of redundant (systemd) services in Debian templates?
https://groups.google.com/forum/#!topic/qubes-devel/GMHLGQ-YDmc

[adrelanos]

How to get rid of redundant (systemd) services in Debian templates?
https://groups.google.com/forum/#!topic/qubes-devel/GMHLGQ-YDmc

[adrelanos]

I think this is done and should be closed.

For Debian Templates: get rid of redundant (systemd) services I created #1928.

[adrelanos]

I think this is done and should be closed.

For Debian Templates: get rid of redundant (systemd) services I created #1928.