On 04/10/2017 01:16 PM, Reg Tiangha wrote:
According to the docs, both /home and /usr/local are persistent in an AppVM:
https://www.qubes-os.org/doc/software-update-vm/
The default PATH in a Qubes VM (Debian 8) looks like this:
user@Email:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/user/.local/bin:/home/user/bin
Unless I'm mistaken, it'll search /usr/local/bin first for a binary, and
if it doesn't find it there, it'll go on to the next directory which is
/usr/bin. If it does find it, then the search stops and the /usr/local
version gets executed, correct?
So a silly question: What's stopping an adversary from placing commonly
named but malicious binaries into /usr/local/bin like ls or
qrexec-related binaries? Unless the scripts and programs that call those
programs are hard-coded to use the absolute paths (ex. /bin/dmesg rather
than just dmesg), would there not be a danger that the /usr/local
versions could be invoked instead in *some* situations? Because
/usr/local is persistent, a user may not necessarily know that stuff may
have been placed in that directory, unless they're actively scanning it
for changes, so if they regularly do work in the default bash shell,
they may never know that their 'ls' command or similar may have been
compromised. I don't mind a persistent /home so much since that can be
useful, and I *can* see some use for a persistent /usr/local in some
circumstances, but is there a way to turn the feature off for those who
don't need it and make an AppVM use the TemplateVM's version instead?
Given the default Qubes security model, its not supposed to matter if
malware can persist. Even the read-only nature of root on template-based
VMs is supposed to be only a beneficial footnote.
OTOH, I'd say your inquiry implies that internal VM security matters to
you to at least some degree (no unguarded sudo, etc.) otherwise there is
nothing to distinguish the /rw/usrlocal persistence issue from
persistence via autostart scripts in /home (which can normally run sudo
without any resistence).
With sudo authentication enabled, the question of persistence becomes
similar to that for a standalone VM... if a malware process can escalate
privs (even via a temporary kernel bug) it can persist in the root-owned
/rw/usrlocal even in a template-based VM.
Maybe a better question is: Should we have the ability to turn off
execution of /rw contents in templates?
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/11957389-e9f1-3140-863b-87a6a9396d57%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
