TemplateBasedVMs: make selected files and folders located in the root image persistent- review bind-dirs.sh

[Patrick Schleizer]

With bind-dirs.sh you can make selected files persistent in
TemplateBasedVMs.

What is it useful for?

For example, it is useful for Whonix, sys-whonix. Tor's data dir
/var/lib/tor has been made persistent in the TemplateBased ProxyVM
sys-whonix. So sys-whonix does not require to be a StandaloneVM. And
therefore can benefit from the Tor anonymity feature 'persistent Tor
entry guards' without the overhead of a StandaloneVM.

When will bind-dirs.sh be available?

bind-dirs.sh will likely come with Qubes R3.2. It is not available from
any testing repositories at the moment. Only available by manual
modifications / from source. [6]

What is the purpose of this posting?

- announce bind-dirs.sh
- document it
- encouragement of review by the community
- discussing current limitations
- brainstorming of potential solutions to these limitations
- fixing limitation [2] would help implementing a TemplateBased sys-vpn.
(By using VPN-Firewall. - A project maintained by me that could
theoretically in future provide a bulletproof sys-vpn implementation,
that (in development branch) also defeats 'fixed shared VPN/Tor server
leak bug'[5] - There will be a separate thread about vpn-firewall soon.)
- help is welcome!

How the configuration for some directory binding would look like?

/rw/config/qubes-bind-dirs.d/50_user.conf

binds+=( '/var/lib/tor' )
binds+=( '/var/lib/whonix' )
binds+=( '/var/lib/whonixcheck' )
binds+=( '/var/cache/whonix-setup-wizard' )
binds+=( '/var/cache/qubes-whonix' )
binds+=( '/etc/tor' )
binds+=( '/etc/hosts' )
binds+=( '/etc/testfile' )
binds+=( '/etc/testsymlink' )

Other config folders are sourced in order (lowest priority)
/usr/lib/qubes-bind-dirs.d /etc/qubes-bind-dirs.d
/rw/config/qubes-bind-dirs.d (highest priority).

Limitations:

[1] Files that exist in the TempalteVM root image cannot be made deleted
in the TemlateBasedVMs root image using bind-dirs.sh.

[2] Does not work if the file / folder in question does not already
exist in the root image. I.e. a file that does not exist in the root
image cannot be bind mounted in the TemplateBasedVM.

[3] Re-running /usr/lib/qubes/bind-dirs.sh without previous umount does
not work yet.

[4] Running '/usr/lib/qubes/bind-dirs.sh umount' after boot (before
shutdown) is probably not sane and nothing can be done about that.

Any ideas on how to overcome any of these?

on github:

https://github.com/marmarek/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh

Credits:

The original concept was created by nrgaway and specific to Whonix. Made
generic and mostly rewritten by me.

Cheers,
Patrick

[5] https://github.com/adrelanos/vpn-firewall/issues/12
[6] https://github.com/marmarek/qubes-core-agent-linux/pull/58

[Chris Laprise]

On 05/11/2016 09:07 PM, Patrick Schleizer wrote:
> With bind-dirs.sh you can make selected files persistent in
> TemplateBasedVMs.
>
> What is it useful for?
>
> For example, it is useful for Whonix, sys-whonix. Tor's data dir
> /var/lib/tor has been made persistent in the TemplateBased ProxyVM
> sys-whonix. So sys-whonix does not require to be a StandaloneVM. And
> therefore can benefit from the Tor anonymity feature 'persistent Tor
> entry guards' without the overhead of a StandaloneVM.

As first step of community review:

Shouldn't tor data dir be reassigned to /rw/config?

Chris

[Patrick Schleizer]

Chris Laprise:

This is done as per your quote.

( - /var/lib/tor is currently reassigned to /rw/srv/whonix/var/lib/tor
currently as per legacy Whonix specific 'bind-directories'. [1] )

- /var/lib/tor will be reassigned to /rw/bind-dirs/var/lib/tor once
Qubes bind-dirs.sh will be available. [2]

Cheers,
Patrick

[1]
https://github.com/Whonix/qubes-whonix/blob/master/usr/lib/qubes-whonix/bind-directories
[2]
https://github.com/Whonix/qubes-whonix/blob/master/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf

[Patrick Schleizer]

Not yet idempotent.

/usr/lib/qubes/bind-dirs.sh umount

/usr/lib/qubes/bind-dirs.sh

+ for fso_ro in '${binds[@]}'
+ local symlink_level_counter
+ symlink_level_counter=0
+ true
+ '[' -h /var/lib/whonix ']'
+ true '/var/lib/whonix is not a symlink'
+ break
+ true 'fso_ro: /var/lib/whonix'
+ fso_rw=/rw/bind-dirs/var/lib/whonix
+ umount /var/lib/whonix
+ true
+ '[' -n '' ']'
+ '[' -d /var/lib/whonix ']'
+ cp --verbose --no-clobber --archive --recursive --parents
/var/lib/whonix /rw/bind-dirs
cp: ‘/var/lib/whonix’ and ‘/rw/bind-dirs/var/lib/whonix’ are the same file

Any idea?

Cheers,
Patrick

[Patrick Schleizer]

qubes-mount-dirs.service

vs

systemd-tmpfiles-clean.service
systemd-tmpfiles-clean.timer
systemd-tmpfiles-setup-dev.service
systemd-tmpfiles-setup.service

Currently which systemd service runs first is undefined. Any thoughts if
ordering should be added?

Cheers,
Patrick

[Marek Marczykowski-Górecki]

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

Any reason for adding such ordering? Is it about adding some tmpfiles
configuration using bind-dirs? If there is not clear use case, I'd left
this undefined (which may mean starting it concurrently), to not slow
down VM startup.

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

iQEcBAEBCAAGBQJX2oMVAAoJENuP0xzK19csYJcH/021bfeqUAalhDkl8dWe27/4
oAg2rJOqJsgXlxG17aGTvXJlZwmCrVR01s/nE69k8XlsQoPB9LPPltgy28X3b2aW
hMN1K06o7Fh4S3NLQVkMAnQXXLe8HM/U7s67ohEmTzOI5wYD831bUjsllnou3DdK
f9uDqnSpzyatzH/78p7NtPGlPKQcmSDhvA15atFSzbZvPT+Arj8IFVXoxiZZ8+pY
ta8YakoiOMfcA0FrOySa/A+gdHL6GZQ9mAPO2KcRHPfREtL4iwIv4KJw8DfNegHd
xtHsy9av8FjfLAcLspXxivE9phy9IE7FGg+HNSCN1Z8RrroH75SeDCgh4ABEiA0=
=375H
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> On Fri, Sep 09, 2016 at 04:38:00PM +0000, Patrick Schleizer wrote:
>> qubes-mount-dirs.service
>
>> vs
>
>> systemd-tmpfiles-clean.service
>> systemd-tmpfiles-clean.timer
>> systemd-tmpfiles-setup-dev.service
>> systemd-tmpfiles-setup.service
>
>> Currently which systemd service runs first is undefined. Any thoughts if
>> ordering should be added?
>
> Any reason for adding such ordering? Is it about adding some tmpfiles
> configuration using bind-dirs? If there is not clear use case, I'd left
> this undefined (which may mean starting it concurrently), to not slow
> down VM startup.

No reason for now. Was just wondering if someone has any thoughts on this.

One use case I can think of if someone wanted to bind-dirs files/folders
in /usr/lib/tmpfiles.d. Then bind-dirs should start before systemd-tmpfiles.

We can leave it undefined for now indeed as long as no one suggest any
use case.