disposible vms for sys-net, firewall, usb?

[Stumpy]

Hi,
I was customizing my dvm templates and of course had to refer to the
docs (thanks doc maintainers/contributors!!!!!) and it mentioned that
dvms could be used for things like sys-net usb and firewall which had
never occured to me.
I may not be thinking about it right but that seemed like a really good
security idea, so my question is, why is that not the default? Just
curious, i suppose the same could be said about why arent vms hardened
by default (which i get the impression is because its a bit of a PITA).
Anyway, i'd be curious to know.
Thanks!

[799]

Hello,

Stumpy <stu...@posteo.net> schrieb am Sa., 23. Feb. 2019, 17:58:

(...) dvms could be used for things like sys-net usb and firewall which had never occured to me.
I may not be thinking about it right but that seemed like a really good security idea, so my question is, why is that not the default? (...)

I am also heavily interested in running "named" disposable VMs as sys-VMs with one enhancement, that I am able to store the Wifi-Credentials in a Vault-VM and that I can "push" the credentials into the sys-net VM when launching it (maybe by some custom scripts which use qvm-run --pass-io from dom0 to copy data from Vault-VM to the Sys-Net-VM).

- O

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Feb 23, 2019 at 10:15:32PM +0100, 799 wrote:
> Hello,
>
> Stumpy <stu...@posteo.net> schrieb am Sa., 23. Feb. 2019, 17:58:
>
> > (...) dvms could be used for things like sys-net usb and firewall which
> > had never occured to me.
> > I may not be thinking about it right but that seemed like a really good
> > security idea, so my question is, why is that not the default? (...)
>
>
> I am also heavily interested in running "named" disposable VMs as sys-VMs

Take a look here:
https://www.qubes-os.org/doc/disposablevm-customization/#using-static-disposablevms-for-sys-

Multiple different DispVMs is a feature new in Qubes 4.0 and we're still
exploring what would be the best configuration for disposable sys-*.

> with one enhancement, that I am able to store the Wifi-Credentials in a
> Vault-VM and that I can "push" the credentials into the sys-net VM when
> launching it (maybe by some custom scripts which use qvm-run --pass-io from
> dom0 to copy data from Vault-VM to the Sys-Net-VM).

The above documentation cover this with another solution - have separate
DVM template for it. This have one important advantage - will work
universally regardless of configuration/tools you use, including custom
VPN scripts etc.

- --
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-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxx0jUACgkQ24/THMrX
1yy4fQf8Ctbpd5mFk1BVx8O5EihKiJCTCFKPdUNECZ4NMRa6O3BJb2BgPR3uREu5
N+fBnDtBIrIvKADgO4LlA0FRFqKnmgwcMjOUXHu8RpFV+CjdeoJMytw9d/LWh23B
w59/UQonxery+jgIgfaK86+Z6JvcytABeeZp88YOGainNEGY3YDLJMPDTf8MKrwI
B+6vNdvoW6po7fC+wiO8PmNJ0flhnTfK4VutM2zY8/x6b3koYnPCbRXwlv6IrVMt
k22WkCPcw90TX9AmPIo6mzn6vjwOMrPvgmpRVa9qiUeey3ww6soZ8VIupOlIBHOt
cpHOd4JXml6SJY7MwmVUrgW0b3pIVg==
=PfGZ
-----END PGP SIGNATURE-----

[Chris Laprise]

On 2/23/19 4:15 PM, 799 wrote:
> Hello,
>

> Stumpy <stu...@posteo.net <mailto:stu...@posteo.net>> schrieb am Sa.,

As you may already know, I created a Qubes service that provides most of
the benefits of a dispVM by removing, hash checking, repopulating or
whitelisting the contents of a VM's private volume:

https://github.com/tasket/Qubes-VM-hardening

It comes with a default that preserves Network Manager connection info
for sys-net. The default also lets most /home files remain, but the
executable parts are locked down with the immutable flag. This default
can be changed to remove and/or repopulate the entire /home contents
(along with everything else in /rw).

Settings can be universal or for each individual VM, which allows
layered customizations to be made without the need to create additional
templates. (All settings are erased in the VM instance before startup is
completed.)

All of this happens immediately before Qubes first mounts the /rw
private volume at startup.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[799]

Hello Chris,

On Sun, 24 Feb 2019 at 00:22, Chris Laprise <tas...@posteo.net> wrote:

[...]

As you may already know, I created a Qubes service that provides most of
the benefits of a dispVM by removing, hash checking, repopulating or
whitelisting the contents of a VM's private volume:

https://github.com/tasket/Qubes-VM-hardening

 [...]

I'd like to test your script, but I need some more information how to start.

As far as I understand, I need to deploy your scripts in a template VM and your script will do some magic, that the AppVM (made from this template) starty in a fresh way (like a disposable VM) but it is possible to add changes which survives between reboots?

Can you give some more details for a complete walkthrough?

For example how to I enable a service? Via the Qubes Settings > Services Tab?

Also I haven't fully understand what happens when I enable the vm-boot-protect service

- O

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Your question is answered here:

https://github.com/QubesOS/qubes-issues/issues/3704

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxzCeEACgkQ203TvDlQ
MDD7cg//fl5ZSTa9MWIN6I+oJwxIimaQKXhdix4n0aTnitnYF73bYqKnYHnqCHdH
JW1KsB8fl9fv2rPFxGWnKULAKWUqRF+WF0+WmQVEZo3uR2BWNq5uSLJQkiZ+Eb0N
wR6dZ3c1ucGFRuLp2zRaYpk7D/t7hFnQw9IAIhGhvMCQTTlssZiopHd+B8aXTyb1
przlfqwqDEZCVR1dqwKRJwruBS6D+8Z5vrDS53t4cErIDbwrJRE/qdmneWxPv2U9
ES17O4F5cO5AbsLfnjspE7ooMzhJAZwiek5NZCTtoj9NsnvW79BU0sUk0i/uRYla
SgRvHuh82PWG53QGffkqN88RMWGwldYcoJYU0o2Opdf9T9zs8J96ZsqCRUe/qQnj
bhfR1So8lTN1EDZf4+z12lP88BtxicHv0p5i6EuaEJRJ/sNhVO7kBet/s4ttKeji
rn6WljZheD/tN3S3x3PCHTCU4acC7Dg4nsO2d3JWF+MaOsKKI1bJjmVavETmBuen
DN5CqZeMH28DWc4hlCZCEsuJdduJJQq68+r4jYtX+UcsEDa47k4sVjxkQVnJ/ntw
awExytKlaZs8+/sIUkSOStSC183Dc8ca89E96itywjwrdMqI+GC07M07isaw6bJE
lfTOOgAl+Tuo8I8+duD4M4Y/aeTWkaUbdk65sEw+IWXlax7Pj9Y=
=B0bb
-----END PGP SIGNATURE-----

[Chris Laprise]

On 2/24/19 3:26 PM, 799 wrote:
> Hello Chris,
>
> On Sun, 24 Feb 2019 at 00:22, Chris Laprise <tas...@posteo.net
> <mailto:tas...@posteo.net>> wrote:
>
> [...]
> As you may already know, I created a Qubes service that provides
> most of
> the benefits of a dispVM by removing, hash checking, repopulating or
> whitelisting the contents of a VM's private volume:
>
> https://github.com/tasket/Qubes-VM-hardening
>  [...]
>
>
> I'd like to test your script, but I need some more information how to start.
> As far as I understand, I need to deploy your scripts in a template VM
> and your script will do some magic, that the AppVM (made from this
> template) starty in a fresh way (like a disposable VM) but it is
> possible to add changes which survives between reboots?

Its installed in a template VM, and any VM based on that template can
use it.

Where a dispVM destroys/creates a new private volume for each run, Qubes
VM Hardening keeps the same volume but can remove or check any/all files
before the VM has a chance to access them.

>
> Can you give some more details for a complete walkthrough?
> For example how to I enable a service? Via the Qubes Settings > Services
> Tab?

Yes. It creates a Qubes service, and that's where you enable it for
individual VMs (otherwise it does nothing, even if it was installed).

The service name to use in your case is 'vm-boot-protect-root' because
that has the "/rw executable deactivation, whitelisting, checksumming"
etc. You can think of it as an automatic "file wiper" that cleans /rw
before the VM has a chance to access it.

>
> Also I haven't fully understand what happens when I enable the

> /vm-boot-protect service

Its all the same service, but using "vm-boot-protect" tells it to only
make /home scripts immutable. This only protects against unprivileged
malware, which is not really the threat model for 'sys-net'.

Using "vm-boot-protect-root" can wipeout malware even if it got root
access in the VM at some point. So if you were using a public wifi
router that successfully attacked your 'sys-net' and installed
persistent malware files in one of the privileged (root-accessible)
paths that are executed by Qubes on startup, this would automatically
quarantine them the next time 'sys-net' was started.

Here's a rundown of its actions at startup:

1. Mount private volume in an 'offline' area so it is not recognized by
the system.

2. Move everything in the /rw privileged directories to
'/rw/vm-boot-protect', effectively a quarantine. By default these dirs
are /rw/config, /rw/bind-dirs, /rw/usrlocal.

Anything defined in a whitelist is exempted. The only default whitelist
is for 'sys-net' and contains:

/rw/config/NM-system-connections/

3. Run hash checks if any were configured by the user. These are just
SHA256 checksum listings. If any check fails, normal VM startup will be
halted and a rescue shell will appear.

4. Copy any files that were configured for deployment. This allows you
to automatically place pristine or special files into /rw at each boot.

5. Dismount the private volume and allow normal VM startup to resume
(e.g. private volume will be re-mounted in the normally recognized place
at /rw).