Create management/pre-configuration stack

[marmarek]

The purpose of this feature is to ease configuration of typical use cases. For example:

• setting up Whonix (install templates, create ProxyVM, AppVMs etc)
• configure SplitGpg (create (offline) VMs, setup RPC policy, adjust VM settings)

In the first stage (scheduled for R3.1) this is just about initial
configuration. Later we may want to use the same stack for maintaining system
configuration (aka management API).

[marmarek]

TODO:

• configuration frontend in firstboot
• disable "Whonix" option, when no Whonix templates selected during installation
• add "Whonix" option to installer
• extract appicons from templates
• create DispVM template

[marmarek]

TODO:

• configuration frontend in firstboot
• disable "Whonix" option, when no Whonix templates selected during installation
• add "Whonix" option to installer
• extract appicons from templates
• create DispVM template

[marmarek]

sys-whonix should be connected to sys-net or sys-firewall? @adrelanos
IMHO sys-net, as there is no sense in setting firewall for tor traffic itself.

[marmarek]

sys-whonix should be connected to sys-net or sys-firewall? @adrelanos
IMHO sys-net, as there is no sense in setting firewall for tor traffic itself.

[adrelanos]

Marek Marczykowski-Górecki:

sys-whonix should be connected to sys-net or sys-firewall? @adrelanos
IMHO sys-net, as there is no sense in setting firewall for tor traffic itself.

---

Reply to this email directly or view it on GitHub:
#1258 (comment)

Hm. Good question.

I'd say sys-firewall. For consistency. Any VM should be connected to
sys-firewall, unless there is a good reason not to.

Then any Qubes specific traffic processing equally applies. [network
lockdown, VPN, ...?)

So would any user extra filtering (IDS) apply. I think that simplified
the setup.

I am wondering which instructions from
https://www.qubes-os.org/doc/qubes-firewall/ would still apply?

For advanced users,

• Enabling networking between two AppVMs
• Port forwarding to an AppVM from the outside world

is still interesting. (Networking between two whonix-ws based AppVMs for
whatever hidden service server setup.) (Or port forwarding from the
outside world to Whonix-Gateway to be able to use the pluggable
transport 'flashproxy' (wording comes from a proxy that 'flashes up',
unrelated to adobe flash).

[adrelanos]

Marek Marczykowski-Górecki:

sys-whonix should be connected to sys-net or sys-firewall? @adrelanos
IMHO sys-net, as there is no sense in setting firewall for tor traffic itself.

---

Reply to this email directly or view it on GitHub:
#1258 (comment)

Hm. Good question.

I'd say sys-firewall. For consistency. Any VM should be connected to
sys-firewall, unless there is a good reason not to.

Then any Qubes specific traffic processing equally applies. [network
lockdown, VPN, ...?)

So would any user extra filtering (IDS) apply. I think that simplified
the setup.

I am wondering which instructions from
https://www.qubes-os.org/doc/qubes-firewall/ would still apply?

For advanced users,

• Enabling networking between two AppVMs
• Port forwarding to an AppVM from the outside world

is still interesting. (Networking between two whonix-ws based AppVMs for
whatever hidden service server setup.) (Or port forwarding from the
outside world to Whonix-Gateway to be able to use the pluggable
transport 'flashproxy' (wording comes from a proxy that 'flashes up',
unrelated to adobe flash).

[marmarek]

The only traffic from sys-whonix is Tor, so filtering on it would be pretty useless. But yes, having sys-firewall as a central place for all the VM simplifies some tasks - live moving all the traffic to sys-3g, so forcibly disabling network. In some cases it might make sense to have sys-whonix instead of sys-firewall - so all the traffic will be torified (but no way to set firewall rules).

[marmarek]

The only traffic from sys-whonix is Tor, so filtering on it would be pretty useless. But yes, having sys-firewall as a central place for all the VM simplifies some tasks - live moving all the traffic to sys-3g, so forcibly disabling network. In some cases it might make sense to have sys-whonix instead of sys-firewall - so all the traffic will be torified (but no way to set firewall rules).

[mfc]

An extra VM is an extra memory burden. If firewallvm isn't used/useful as a firewall in this context, then it shouldn't be used by default.

On November 20, 2015 10:08:19 PM GMT+01:00, "Marek Marczykowski-Górecki" notifications@github.com wrote:

The only traffic from sys-whonix is Tor, so filtering on it would be
pretty useless. But yes, having sys-firewall as a central place for
all the VM simplifies some tasks - live moving all the traffic to
sys-3g, so forcibly disabling network. In some cases it might make
sense to have sys-whonix instead of sys-firewall - so all the
traffic will be torified (but no way to set firewall rules).

---

Reply to this email directly or view it on GitHub:
#1258 (comment)

[mfc]

An extra VM is an extra memory burden. If firewallvm isn't used/useful as a firewall in this context, then it shouldn't be used by default.

On November 20, 2015 10:08:19 PM GMT+01:00, "Marek Marczykowski-Górecki" notifications@github.com wrote:

The only traffic from sys-whonix is Tor, so filtering on it would be
pretty useless. But yes, having sys-firewall as a central place for
all the VM simplifies some tasks - live moving all the traffic to
sys-3g, so forcibly disabling network. In some cases it might make
sense to have sys-whonix instead of sys-firewall - so all the
traffic will be torified (but no way to set firewall rules).

---

Reply to this email directly or view it on GitHub:
#1258 (comment)

[adrelanos]

Michael Carbone:

An extra VM is an extra memory burden. If firewallvm isn't used/useful as a firewall in this context, then it shouldn't be used by default.

At the moment sys-net and sys-firewall are automatically started at boot
by Qubes default.

Do you think this should be changed?

Or do you primarily have setups in mind where users disabled the
autostart of these VMs?

Do you think there are enough situations where users are (potentially)
exclusively using torified traffic for everything so they won't be
requiring sys-firewall?

[adrelanos]

Michael Carbone:

An extra VM is an extra memory burden. If firewallvm isn't used/useful as a firewall in this context, then it shouldn't be used by default.

At the moment sys-net and sys-firewall are automatically started at boot
by Qubes default.

Do you think this should be changed?

Or do you primarily have setups in mind where users disabled the
autostart of these VMs?

Do you think there are enough situations where users are (potentially)
exclusively using torified traffic for everything so they won't be
requiring sys-firewall?

[adrelanos]

Marek Marczykowski-Górecki:

The only traffic from sys-whonix is Tor, so filtering on it would be pretty useless.

There are still some thing one can filter.

• quota
• bandwidth
• IPs ( ex:
  https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/BridgeFirewall
  )
• ports

Okay, these are probably all minority use cases.

So either way, this shouldn't be a hard limitation. I mean, the user
should not be forced to use either or have its decision reverted to use
the other one. [To allow advanced filter combinations.] Hopefully this
is doable with the pre-configuration stack.

[adrelanos]

Marek Marczykowski-Górecki:

The only traffic from sys-whonix is Tor, so filtering on it would be pretty useless.

There are still some thing one can filter.

• quota
• bandwidth
• IPs ( ex:
  https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/BridgeFirewall
  )
• ports

Okay, these are probably all minority use cases.

So either way, this shouldn't be a hard limitation. I mean, the user
should not be forced to use either or have its decision reverted to use
the other one. [To allow advanced filter combinations.] Hopefully this
is doable with the pre-configuration stack.

[marmarek]

An extra VM is an extra memory burden. If firewallvm isn't used/useful as a firewall in this context, then it shouldn't be used by default.

This would be true only in case of all the VM connected to Whonix Gateway. Otherwise sys-firewall is still usable.
Anyway, we have two options for default settings (easily changeable later):

• connect sys-whonix to sys-firewall - one step less for advanced configurations, more memory usage, even in all the VMs connected to Whonix-gw
• connect sys-whonix to sys-net - less memory footprint for whonix-only setups, a little more steps for advanced configs

In case of sys-whonix->sys-net, autostarting sys-firewall may be disabled.

[marmarek]

An extra VM is an extra memory burden. If firewallvm isn't used/useful as a firewall in this context, then it shouldn't be used by default.

This would be true only in case of all the VM connected to Whonix Gateway. Otherwise sys-firewall is still usable.
Anyway, we have two options for default settings (easily changeable later):

• connect sys-whonix to sys-firewall - one step less for advanced configurations, more memory usage, even in all the VMs connected to Whonix-gw
• connect sys-whonix to sys-net - less memory footprint for whonix-only setups, a little more steps for advanced configs

In case of sys-whonix->sys-net, autostarting sys-firewall may be disabled.

[adrelanos]

It's all minor advantages/disadvantages either way for minority use cases either way.

Another small reason for sys-firewall is people less concerned freaking out asking "Why sys-whonix is [no longer | not] connected to sys-firewall? Keeping the FUD level low.

[adrelanos]

It's all minor advantages/disadvantages either way for minority use cases either way.

Another small reason for sys-firewall is people less concerned freaking out asking "Why sys-whonix is [no longer | not] connected to sys-firewall? Keeping the FUD level low.

[marmarek]

Implemented, mostly by @nrgaway.

[marmarek]

Implemented, mostly by @nrgaway.

[nrgaway]

I will have time to finish anything outstanding starting next week

On 23 November 2015 at 17:29, Marek Marczykowski-Górecki <
notifications@github.com> wrote:

Implemented, mostly by @nrgaway https://github.com/nrgaway.

—
Reply to this email directly or view it on GitHub
#1258 (comment)
.

[nrgaway]

I will have time to finish anything outstanding starting next week

On 23 November 2015 at 17:29, Marek Marczykowski-Górecki <
notifications@github.com> wrote:

Implemented, mostly by @nrgaway https://github.com/nrgaway.

—
Reply to this email directly or view it on GitHub
#1258 (comment)
.