proposal to move from /rw to /usr/local for new Qubes developments

[Patrick Schleizer]

There are a few Qubes specific configuration files such as:

- /rw/config/qubes-bind-dirs.d/50_user.conf
- Qubes-Whonix specific /rw/config/whonix_firewall.d
- and a few other examples.

/rw is a non-standard folder.

I think we can standardize this a bit. Examples:

- /usr/local/etc/qubes-bind-dirs.d/50_user.conf
- Qubes-Whonix specific /usr/local/etc/whonix_firewall.d

(/usr/local is stored in /rw anyhow.)

I don't propose abolishing existing implementations using /rw.

- It would suffice if we keep this in mind for new developments. I.e. if
some new Qubes functionality wants provide TemplateBasedVM specific "/rw
style" settings, make that '/usr/local/etc/...' instead.

- We could add parsing /usr/local to existing components (such as
qubes-bind-dirs etc.).

- Best to keep it backwards compatible, i.e. to keep parsing /rw/ for
bind-dirs etc.

Why?

- /usr/local is an FHS standard. [1]

- Other applications support /usr/local/etc. (Search engines say so.)
(corridor does.) - For users it's best if it's kept uniform rather than
having a standardized and Qubes specific location.

- If feature requests are made / patches are proposed against third
party applications (let's say for example against onionshare, Tor
Browser), then it is more likely to have a request for the standardized
/usr/local rather than Qubes specific /rw folder accepted.

What do you think?

Best regards,
Patrick

[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html

[Chris Laprise]

On 12/20/2016 06:35 PM, Patrick Schleizer wrote:
> - /usr/local/etc/qubes-bind-dirs.d/50_user.conf
> - Qubes-Whonix specific /usr/local/etc/whonix_firewall.d
>
> (/usr/local is stored in /rw anyhow.)
>
> I don't propose abolishing existing implementations using /rw.
>
> - It would suffice if we keep this in mind for new developments. I.e. if
> some new Qubes functionality wants provide TemplateBasedVM specific "/rw
> style" settings, make that '/usr/local/etc/...' instead.
>

Before including standard config paths into the template-based scheme
for private storage, I think we have to ask how many other non-Qubes
programs will end up using these paths and thus inadvertently causing
settings and scripts to persist. And under what conditions does this
become undesirable? Would malware that is not Qubes-aware try to
propagate through a folder like /usr/local/etc?

Chris

[Patrick Schleizer]

Chris Laprise:

Since Qubes R3.0 [and probably also earlier] /usr/local is already
stored in /rw anyhow. Therefore my suggestion does not change anything
about inadvertent /usr/local persistence.

Inadvertent /usr/local persistence however is an interesting separate
question.

Best regards,
Patrick

[Andrew David Wong]

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

I think this last question lies outside the Qubes threat model,
since TemplateBasedVM rootfs nonpersistence isn't exactly
intended to be a security feature, at least not in that way:

https://www.qubes-os.org/attachment/wiki/slides/LinuxCon_2014_Qubes_Tutorial.pdf

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

iQIcBAEBCgAGBQJYWj6aAAoJENtN07w5UDAwL5EQAIhQKKldSVclGvxWb2s7bKRY
I4qKEWuxY2BwXDbvGk1/eE20VxwMaQZEj5C7y+gukP85w5y4lZ2h3tvmZfDYrtM6
LRIR0NTlMbuybmPdGodNK8WwppshN+pBAfQFLdZa0GLfXSryPYeFUr2EemZPGL5x
hEn9Xl0pEC0P+MXbzeFfgun/V6bGlcHNjOOLTJBM87KQpveFeEezD3z5ueZ96iPD
MGaCOxW/mTpi8aXdCTPb6bEfyZ3ROC9BcYxi7Oetq8zYPYUBtkJc520E68vha64x
0YQHGEekbu0/6QYXqvvfXw3NfFt6iKxipEJTAy1eMW0fO6up3nL+P3BJYoDIZ3aj
NfZTbU9LZXR/iycnDuFCbqDMZtb0nXO5RHt4RfkSibXfDhxi7zDSsUj2LTNxZ8w7
kgb60WXY4BbRzARTfRxCbIf0I39q80k3X5sJK60mx8CP5gxOjLuKe26YY+MA+B2g
oSpGGZ0QQF4Xdpl2JFtNY6GG3VBS2jNpgkRD+kAgQB+7TUMu4VY+G7rbIenQi+8L
nVP6Nju7HglhOqTY4kR0OZEsMYA7v591SdilrCUX/zKIiPzfCrNQ93usk6qUdY5Y
WghiFve2eYYU7GDlVe7XxhUxpZMrFp7PDGtuIw/C5hxr2v6cdSzAmqXOLlbuTwUV
GQKxL+Rd0cfTpu7gVRQB
=mPpe
-----END PGP SIGNATURE-----

[Unman]

I dont understand the last point. If we wanted feature request or
patches why propose them in /rw when we could already propose them in
/usr/local and fit both Qubes and upstream?

Personally I prefer to see less in /rw than there is now. I don't really
like the use of bind mounts for cron , use of /usr/local, and
bind-dirs.

If I understand your proposal properly then from now on there will be a
mix of stuff in /rw/config and /usr/local/etc/. I'm not clear how that
is supposed to make it more unifornm for users, whereas just pointing
to /rw/config as the standard part of template based qubes seems clear and
understandable to me.

unman

[Marek Marczykowski-Górecki]

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

On Tue, Dec 20, 2016 at 11:35:00PM +0000, Patrick Schleizer wrote:

> There are a few Qubes specific configuration files such as:
>
> - /rw/config/qubes-bind-dirs.d/50_user.conf
> - Qubes-Whonix specific /rw/config/whonix_firewall.d
> - and a few other examples.
>
> /rw is a non-standard folder.
>
> I think we can standardize this a bit. Examples:
>
> - /usr/local/etc/qubes-bind-dirs.d/50_user.conf
> - Qubes-Whonix specific /usr/local/etc/whonix_firewall.d
>
> (/usr/local is stored in /rw anyhow.)

It looks you're actually proposing using /usr/local/etc instead of
/rw/config. Not /usr/local instead of /rw. So for example /home is left
as /rw/home (and bind-mounted to /home), not moved to /usr/local/home
(and bind-mounted from there).

> I don't propose abolishing existing implementations using /rw.
>
> - It would suffice if we keep this in mind for new developments. I.e. if
> some new Qubes functionality wants provide TemplateBasedVM specific "/rw
> style" settings, make that '/usr/local/etc/...' instead.
>
> - We could add parsing /usr/local to existing components (such as
> qubes-bind-dirs etc.).
>
> - Best to keep it backwards compatible, i.e. to keep parsing /rw/ for
> bind-dirs etc.

So, in practice, for any tool supporting /rw/config currently, you
propose to change places searched for configuration:

from: /rw/config, /etc
to: /usr/local/etc, /rw/config, /etc

And for the new software, use only: /usr/local/etc, /etc.

Is that right?

> Why?
>
> - /usr/local is an FHS standard. [1]
>
> - Other applications support /usr/local/etc. (Search engines say so.)
> (corridor does.) - For users it's best if it's kept uniform rather than
> having a standardized and Qubes specific location.

- From my experience most applications support _either_ /usr/local/etc or
/etc. Depending on how was built. But not both. So, we'd still need to
bind-mount/copy/symlink selected configuration to have it persistent.
The only difference would be location (/usr/local/etc vs /rw/config),
but the operation would be needed anyway.

> - If feature requests are made / patches are proposed against third
> party applications (let's say for example against onionshare, Tor
> Browser), then it is more likely to have a request for the standardized
> /usr/local rather than Qubes specific /rw folder accepted.

This is fair point, but I don't think it's any standard to look for
configuration first in /usr/local/etc then fallback to /etc. That would
still be Qubes-specific _in practice_. But indeed more likely to be
accepted.

I think very similar use case is diskless system, started from some
read-only network share. And according to my experience, such setups use
some kind of filesystem level overlay (aufs/unionfs/overlayfs) to place
host-specific configuration files in alternative location. So,
/usr/local doesn't look to be a solution there either.

> What do you think?

Generally, I agree that /rw choice might not be the best one in the
first place. But /rw is well established in Qubes OS for years and I'm
also not sure if the change would improve much.
For existing users, the change (even when keeping /rw/config
compatibility) will be a problem - there surely will be inconsistencies
in the transitional time etc. Will it be easier for new users to use
/usr/local/etc instead of /rw/config? I don't know. On Linux both are
unexpected places to put configuration in. On the other hand, it would
be more familiar for FreeBSD users.

So, I'm slightly against this change. Unless some other benefits will be
found, to justify all the issues with the change itself.

> [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html

PS /usr/local/etc is longer to type than /rw/config ;)

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

iQEcBAEBCAAGBQJYXUw7AAoJENuP0xzK19csMF0H+wR8rnlyWy/mknTmuhmF6LQI
Qeg9rH08Le2DRKNlhyTC1celphacBImPMuOSlFLv43a/W7cIWsdzCAJ6QpmVHRzg
VgP2aVRz6xehu0Az+0IJrb2pnkJYlLoacIW3sOBRqBQ9RyZsWe7udiPN0K+U2jGW
37Ee1//YPGOt6B8nGWfxkWHQtATvY1XcdacRBeZUyQs4vrj5n3dMjD5oOdwB/oud
tsACzUKRq/utoSTyuj7AmeLZJ9c7QcKlitaNYKVbfQIqnZ/T7F9yuf4AvBLhtAzi
jpMUf9Gzy3HWGjBzX2CpYNwDyJLUriiVfVDGtzpNIQUCT/xnKO/3pa+TNgr9YHo=
=Mewh
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> On Tue, Dec 20, 2016 at 11:35:00PM +0000, Patrick Schleizer wrote:
>> There are a few Qubes specific configuration files such as:
>
>> - /rw/config/qubes-bind-dirs.d/50_user.conf
>> - Qubes-Whonix specific /rw/config/whonix_firewall.d
>> - and a few other examples.
>
>> /rw is a non-standard folder.
>
>> I think we can standardize this a bit. Examples:
>
>> - /usr/local/etc/qubes-bind-dirs.d/50_user.conf
>> - Qubes-Whonix specific /usr/local/etc/whonix_firewall.d
>
>> (/usr/local is stored in /rw anyhow.)
>
> It looks you're actually proposing using /usr/local/etc instead of
> /rw/config. Not /usr/local instead of /rw.

Yes.

> So for example /home is left
> as /rw/home (and bind-mounted to /home), not moved to /usr/local/home
> (and bind-mounted from there).

Yes, because I haven't seen /usr/local/home in FHS.

site:pathname.com "/usr/local/home"

>> I don't propose abolishing existing implementations using /rw.
>
>> - It would suffice if we keep this in mind for new developments. I.e. if
>> some new Qubes functionality wants provide TemplateBasedVM specific "/rw
>> style" settings, make that '/usr/local/etc/...' instead.
>
>> - We could add parsing /usr/local to existing components (such as
>> qubes-bind-dirs etc.).
>
>> - Best to keep it backwards compatible, i.e. to keep parsing /rw/ for
>> bind-dirs etc.
>
> So, in practice, for any tool supporting /rw/config currently, you
> propose to change places searched for configuration:
>
> from: /rw/config, /etc
> to: /usr/local/etc, /rw/config, /etc
>
> And for the new software, use only: /usr/local/etc, /etc.
>
> Is that right?

Yes.

>> Why?
>
>> - /usr/local is an FHS standard. [1]
>
>> - Other applications support /usr/local/etc. (Search engines say so.)
>> (corridor does.) - For users it's best if it's kept uniform rather than
>> having a standardized and Qubes specific location.
>
> - From my experience most applications support _either_ /usr/local/etc or
> /etc. Depending on how was built. But not both. So, we'd still need to
> bind-mount/copy/symlink selected configuration to have it persistent.
> The only difference would be location (/usr/local/etc vs /rw/config),
> but the operation would be needed anyway.

I see.

Yes, bind-dirs wouldn't be replaced by this.

>> - If feature requests are made / patches are proposed against third
>> party applications (let's say for example against onionshare, Tor
>> Browser), then it is more likely to have a request for the standardized
>> /usr/local rather than Qubes specific /rw folder accepted.
>
> This is fair point, but I don't think it's any standard to look for
> configuration first in /usr/local/etc then fallback to /etc. That would
> still be Qubes-specific _in practice_. But indeed more likely to be
> accepted.
>
> I think very similar use case is diskless system, started from some
> read-only network share. And according to my experience, such setups use
> some kind of filesystem level overlay (aufs/unionfs/overlayfs) to place
> host-specific configuration files in alternative location. So,
> /usr/local doesn't look to be a solution there either.

Okay.

>> What do you think?
>
> Generally, I agree that /rw choice might not be the best one in the
> first place. But /rw is well established in Qubes OS for years and I'm
> also not sure if the change would improve much.
> For existing users, the change (even when keeping /rw/config
> compatibility) will be a problem - there surely will be inconsistencies
> in the transitional time etc. Will it be easier for new users to use
> /usr/local/etc instead of /rw/config? I don't know. On Linux both are
> unexpected places to put configuration in. On the other hand, it would
> be more familiar for FreeBSD users.
>
> So, I'm slightly against this change. Unless some other benefits will be
> found, to justify all the issues with the change itself.
>
>> [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html
>
> PS /usr/local/etc is longer to type than /rw/config ;)
>
>

Thank you for your consideration! :)

Best regards,
Patrick