Should Bind-dirs be app qube-editable? (minimal state app qubes)

[deeplow]

Hello,

Disposable qubes are the gold-standard in mitigation malware persistence, but in the context of an app qubes one only needs to store a malicious script in /rw/config/rc.local to get persistence. #1006 and #3258 add interesting points about making only bind-dirs be all that persists in an app qube. Getting persistence in a white-list style bind-dirs would require an attacker to exploit applications which read persisted configuration files / directories instead of just a simple bash script. 

Further hardening of certain applications would become possible. For example

• storing network configurations in sys-net
  
• storing browser profiles
• etc.

However, even if said mitigations were to be implemented, bind-dirs would still editable within the app qube through /rw/config/qubes-bind-dirs.d (highest priority, for per VM configuration), which 3hhh hints at. This makes such eventual persistence mitigations irrelevant from within app qubes.

So my suggestion is: now that we have a way to expose configuration values to to qubes (through vm-config), to have bind-dirs stored as a vm-config, potentially replacing /rw/config/qubes-bind-dirs.d. This way it would editable only from its AdminVM (kind of like firewall rules). In particular for sys-net, this would open up the possibility of having salt set said bind-dirs by default and have only networks configurations persist.

Best regards,

deeplow

[Marek Marczykowski-Górecki]

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

On Thu, Sep 26, 2024 at 02:48:18PM +0000, 'deeplow' via qubes-devel wrote:
> Hello,
>

> Disposable qubes are the gold-standard in mitigation malware persistence, but in the context of an app qubes one only needs to store a malicious script in /rw/config/rc.local to get persistence. [#1006](https://github.com/QubesOS/qubes-issues/issues/1006#) and [#3258](https://github.com/QubesOS/qubes-issues/issues/3258) add interesting points about making only bind-dirs be all that persists in an app qube. Getting persistence in a white-list style bind-dirs would require an attacker to exploit applications which read persisted configuration files / directories instead of just a simple bash script.

>
> Further hardening of certain applications would become possible. For example
>

> - storing network configurations in sys-net
> - storing browser profiles
> - etc.
>
> However, even if said mitigations were to be implemented, bind-dirs would still editable within the app qube through /rw/config/qubes-bind-dirs.d (highest priority, for per VM configuration), which [3hhh hints at](https://github.com/QubesOS/qubes-issues/issues/3258#issuecomment-725516370). This makes such eventual persistence mitigations irrelevant from within app qubes.
>
> So my suggestion is: now that we have a way to expose configuration values to to qubes (through [vm-config](https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html#vm-config)), to have bind-dirs stored as a vm-config, potentially replacing /rw/config/qubes-bind-dirs.d. This way it would editable only from its AdminVM (kind of like firewall rules). In particular for sys-net, this would open up the possibility of having salt set said bind-dirs by default and have only networks configurations persist.

I like this!

We could put that into vm-config, or even have a new place
(bind-dirs prefix?). If present, configuration in /rw/config would be
ignored, and maybe also /home not bind-mounted anymore (unless
listed in bind-dirs explicitly?). One remaining question is interaction
with template-stored configuration (/usr/lib/qubes-bind-dirs.d) - I
guess it should be respected in that case, correct?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb1dfEACgkQ24/THMrX
1yzfIwf9GIw3cKl4SOYkhjw0GyTy01viP0tYSJ39BOivq7gXnQii2SQ1cm49fDu+
Dh76xSqxYnTIUZ8w3ACNG8+gbdlT6GlLca5j1DNVFHGNApk6BPI6dVy83I/p3HV2
AJsE2m9N4dzHjtdShCZpjIJJU3855yCmn7cQyrYopXeignce5NfSzHsi/y+l4zYo
sdkp5GCVEvJPfGhhv62y43s6458U2g2Pl8OKYqel4E9Zcw/waZOWn23ziw17yOm8
dqwGVmb1cxJ5Xr078Ke1faIk0koavrQaz7+rlGe7+RCsZ8Cal3cO3UT7aVmVSIa5
6O0FDvBcCQcTXooGEeAmz7rfYjAi0w==
=qpTD
-----END PGP SIGNATURE-----

[deeplow]

On Thursday, September 26th, 2024 at 3:55 PM, Marek Marczykowski-Górecki <marmarek at invisiblethingslab.com> wrote:
> I like this!

Nice!

> We could put that into vm-config, or even have a new place
> (bind-dirs prefix?).

A dedicated prefix sounds even better! Perhaps even a chance to get
a less implementation-specific name like "persistent-app-dirs".
But either way is even better than (ab)using vm-config.

> If present, configuration in /rw/config would be ignored and

> maybe also /home not bind-mounted anymore (unless
> listed in bind-dirs explicitly?).

I think /home could be added by default to this bind-dirs prefix
when creating a new qubes otherwise getting started on Qubes would
even be more difficult. Installed programs in app qubes "mysteriously
disappearing" is a commonly reported issue in the forum.

So my suggestion would be to keep the default experience, but allowing
advanced users to remove /home persistence if desired. This way we'd
keep regular users happy (because nothing broke) and advanced users with
yet another tool in their toolbox.

One aspect to also think about is how to do this "default home persist"
in a multi-OS way. Perhaps the default bind-dirs could be obtained
template's preferences. Maybe stored in "os-home-dirs"?

> One remaining question is interaction
> with template-stored configuration (/usr/lib/qubes-bind-dirs.d) - I
> guess it should be respected in that case, correct?

Yes, I think it is reasonable to keep honoring template bind-dirs.
After all, a malicious template can do much more than mess with bind-dirs.

Best regards,
deeplow

[Marek Marczykowski-Górecki]

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

On Thu, Sep 26, 2024 at 03:22:41PM +0000, deeplow wrote:
> On Thursday, September 26th, 2024 at 3:55 PM, Marek Marczykowski-Górecki <marmarek at invisiblethingslab.com> wrote:
> > I like this!
>
> Nice!
>
> > We could put that into vm-config, or even have a new place
> > (bind-dirs prefix?).
>
> A dedicated prefix sounds even better! Perhaps even a chance to get
> a less implementation-specific name like "persistent-app-dirs".
> But either way is even better than (ab)using vm-config.

One thing to consider is length limitation of qubesdb keys - 63 chars.
Values can be much longer (3k). So, the longer the prefix, the shorter
actual key. But it isn't necessarily a problem, the actual path can be
put as a value, and key could be something short like
"123-my-first-path" (in most cases ordering doesn't matter, but in the
few cases where it does, better to have this numbered prefix).

> > If present, configuration in /rw/config would be ignored and
> > maybe also /home not bind-mounted anymore (unless
> > listed in bind-dirs explicitly?).
>
> I think /home could be added by default to this bind-dirs prefix
> when creating a new qubes otherwise getting started on Qubes would
> even be more difficult. Installed programs in app qubes "mysteriously
> disappearing" is a commonly reported issue in the forum.
>
> So my suggestion would be to keep the default experience, but allowing
> advanced users to remove /home persistence if desired. This way we'd
> keep regular users happy (because nothing broke) and advanced users with
> yet another tool in their toolbox.

Yes, this is kinda what propose: on the backend level, have implicit
default include /home, but if you start configuring it manually, you'd
need to include /home (if desirable) yourself too. Ofc, the (G)UI could
propose this option for you to make it easier.

> One aspect to also think about is how to do this "default home persist"
> in a multi-OS way. Perhaps the default bind-dirs could be obtained
> template's preferences. Maybe stored in "os-home-dirs"?

I don't think any path in bind-dirs setting could be made OS-agnostic...

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb1gPIACgkQ24/THMrX
1yyPaQf/dO8D5v4iNV4HvLeeR82RBIeV0CycJLvQ8Qnc8Viy8eZASau6s4GSaDxC
MVAMGBEUo5o6gengGxuTd4u3kT9OmgfCH9AXbv0p9vGkc6fGkcwYvUvWDNY8sjHG
z6Jf6U+l6RJDt6xTq/wsbEGSo9Ctj41cA5ewb+FjZLcI4Gt2vIIISLt8YCOAVhp5
wQr3bPpxwcSNo/Qi+NPu8fPWeJJsyYDpesdYFnbeC42Qc1UZ1OtiblwF3GN30JCY
sYql4BJD9yiEkbTbgfhBOHOkYElevo92y5xfWgXbLXantzwoo2MJaW8vuGanXbQi
NgshVojXlh/UHYBSEhOCdH3rKoAbVw==
=GwdK
-----END PGP SIGNATURE-----

[deeplow]

(forgot to CC the list)

On Thursday, September 26th, 2024 at 4:42 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
> One thing to consider is length limitation of qubesdb keys - 63 chars.
> Values can be much longer (3k). So, the longer the prefix, the shorter
> actual key. But it isn't necessarily a problem, the actual path can be
> put as a value, and key could be something short like
> "123-my-first-path" (in most cases ordering doesn't matter, but in the
> few cases where it does, better to have this numbered prefix).

Good point. I didn't know about the keys limit.
In practice I think it should be fine both for keys and values.

> > So my suggestion would be to keep the default experience, but allowing
> > advanced users to remove /home persistence if desired. This way we'd
> > keep regular users happy (because nothing broke) and advanced users with
> > yet another tool in their toolbox.
>
> Yes, this is kinda what propose: on the backend level, have implicit
> default include /home, but if you start configuring it manually, you'd
> need to include /home (if desirable) yourself too. Ofc, the (G)UI could
> propose this option for you to make it easier.

Sounds good to me. More or less what I was thinking as well.

> > One aspect to also think about is how to do this "default home persist"
> > in a multi-OS way. Perhaps the default bind-dirs could be obtained
> > template's preferences. Maybe stored in "os-home-dirs"?
>
>
> I don't think any path in bind-dirs setting could be made OS-agnostic...

Totally. I was thinking here about where we could fetch that default
location from. The template's prefs could be a place, but this is a minor
implementation detail.

Best regards,
deeplow

[Demi Marie Obenour]

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

For Windows vs Linux I agree, but at least /home is the same under
almost every *nix I know of.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEopQtqVJW1aeuo9/sszaHOrMp8lMFAmb1jAMACgkQszaHOrMp
8lOv+hAAqbWy3CrpdHJaL2jy+RMAr1CgthLSD0G3FDJ464rpNJ21Jfl4aM7j4KbL
AUTRrgLfMczWYEYCXFHK/l0NyFR7plZaYZoApuMAxUfn5ZnpaTnwS/rfXsCJKx/5
CQXSlRQNjmx8QbYw2vBdcmuYIcGwPeBrTLN+rHr21i6263r5Y+nAnWcUTyLQ2skw
GF8JUZzhTY+7K6YFhbC0NPY9Hp/HisqMH2maLJkILS26oXJOngfmgyBbG8jpJKPB
Q9jtZOIZ+gLX+ZjjMkmRcsiu3rHngrULw2d+YOUA6ObbcqgKJMgm0LFV2YTxO7jS
A+fbpW9qrRTmpje7a2NTCSElgGKgLnF8gUOl0tSkVvbVMeienzw1Crxt4Xy6oNCi
THpoeHgsBjdibCRYDbXz2AGshG4S7ovGOjQtfpcdNuDbZMPcLQSk5j4TRnIJuy5K
DNXoCDlAk5bdbHGzvYo5zZdjVoD7eYWLMq0q0+sbv7uDXij0wyUPZL2CjhBjtZYl
mm9q+c+Fr787IMsguCB0SkgZTE9L0ZYWuJ0TnMbztxgkl7wQZnyLK2zJ+UOgWkdr
uHR6kHm4f7b+pp51hJSDbRmsNUzySY/YNpyMooNBCdpbUIt5duXefxVB6MUJyL27
rhaXPxommnuQ3BGBJ1uvIzdjE5s5u4FhgbFTulYcD+NjY+Li4B4=
=Jzqd
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Yet, there is no qubes-core-agent (nor qubesdb) in any of them, so it's
irrelevant. In any case, there is "os" feature that can be used to
distinguish OSes (that have qubes tools installed), and also we have
proper mechanism for feature discovery - "supported-feature" namespace -
for a template to announce support for this configurable bind-dirs.
That's important, because it isn't enough to say "Qubes 4.3 supports
this" - you may have template imported from 4.2 for example, or some
custom build or whatever. We can use a similar mechanism to give some
hits for the GUI about configuring this thing if needed (which I doubt
will happen anytime soon - I don't see a _practical_ chance for non-Linux
support of this feature happening).

- --
Best Regards,
Marek Marczykowski-Górecki

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb1j+oACgkQ24/THMrX
1yzKKgf9Em2yJ19Z74fB4OPAI+FG5+ZbsiKAK07dDa0FtHM9oPjWnG/Am/YP/KG1
7n/Z9nihN8/qpO+InOVvO+1uiff060rrTy0rdHmjzPMh5eXvXqaJQIfgGd/FOxX+
PLAA+a/LB9zNqS82LdIovIfDe8yZ515zdHje1mDuytCqNR3Zq9YWFRqgDUOOL3+o
OUm74qAJ7sjPOLXdXjbYNSfcuh7wurTNqK4NVSkq1Tvl/ghlbZt3/KTikdmrwen5
j6hRFrhgYer40oAIMkd6pTcPwBlsmooNVs9uopkMv4Py7seE9JQlBM96EQoaZoJx
k6daZDqDNh5P4DJQ49+MpcoWv1fCCw==
=E0pT
-----END PGP SIGNATURE-----

[deeplow]

> > For Windows vs Linux I agree, but at least /home is the same under
> > almost every *nix I know of.
>
>
> Yet, there is no qubes-core-agent (nor qubesdb) in any of them, so it's
> irrelevant. In any case, there is "os" feature that can be used to
> distinguish OSes (that have qubes tools installed), and also we have
> proper mechanism for feature discovery - "supported-feature" namespace -
> for a template to announce support for this configurable bind-dirs.
> That's important, because it isn't enough to say "Qubes 4.3 supports
> this" - you may have template imported from 4.2 for example, or some
> custom build or whatever. We can use a similar mechanism to give some
> hits for the GUI about configuring this thing if needed (which I doubt

> will happen anytime soon - I don't see a practical chance for non-Linux

> support of this feature happening).

True.

I guess practical next steps are to file and issue with the conclusion
of this discussion either on #1006, #3258 and close the other one.
Is this the correct way to go about this? Or does it need anything else?

Best regards,
deeplow

[Marek Marczykowski-Górecki]

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

Yes, #1006 looks like logical place to track this feature.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb3Jd0ACgkQ24/THMrX
1yztAAgAjUlcRSQuPg6Us0Z/NT4ifNML3ZR9waoNYjbd/UgjG0Q8TyQY+yAbNzcz
MBf9el3JhIKn2hTbtDhOz7gjFArAc+JOyB3VsbJgBCAyynlVksT+4tE7Dw9JzvII
+rxHIgEmMeUeeLyY6Q1P95RKGhE1ACLSIHNvddMTBxkVc6GOIEI18RofY4m+PSNT
1UQJ3G1NEjPXYd1qbxhSnTN5SjHgsQo49MLU8S1MhB2kbc0NiVRzid7GDfejjxZb
dN2fhyK0gCPCNt9XQ7Y105Ef0IYo1Y1svu05T8ltPYo+j+NMx/+c76q75dVREij3
/dwHr+RS+fE8sftz/iTE9nS2PZgJbw==
=mxKG
-----END PGP SIGNATURE-----