On 03/14/2017 09:13 AM, sm8ax1 wrote:
I still haven't heard any rebuttals against how sudo can help mitigate
attacks against the virtualization (persistence aside). Without sudo,
unprivileged processes can access /proc/xen/privcmd, raw sockets, memory
mappings, etc., and load kernel modules that have even greater
capabilities. We can be naïve and just assume that Xen and the kernel
are completely secure, or we can be realistic and do a cost-benefit
analysis of enabling Dom0 approval of sudo access.
How often does the average user really have to elevate privileges
anyway? Considering most directories not writable by user:user (with the
notable exception of /usr/local and /rw) are non-persistent anyway, I'm
not sure there's very much legitimate use for sudo. I can't figure out
what use cases would require it so often that clicking "yes" in Dom0
would be especially inconvenient. And I'm speaking in the general case
here; there's nothing to prevent someone from installing a specific VM,
elevating via Dom0 once, and overriding /etc/sudoers via bind-dirs in
that VM (or template) if they have a need for it.
I think if you leave out use of the 'mount' and 'umount' commands, root
access tends to be pretty rare. Even so, this is not something that
regular users of Linux or Mac desktops complain about often (and they
have to type the passwords).
And I'll say it again: all this is in the absence of MACs like SELinux,
AppArmor, or Grsec, or internal firewalls e.g. to restrict access to
localhost. Obviously, if anything like that were enabled, it would be
useless without requiring sudo approval. Since AFAIK there are no plans
to enable anything like this in any of the stock templates, one could
argue that /etc/sudoers should be overridden by specific templates that
need it (have MAC or internal firewalls), but I don't know enough about
the template building process to say.
Well stated.
But I'll add a small caveat: That dash and bash are naive toward their
init files (like ~/.profile) which are writable by user. This means an
attacker's /home/user/.bin/sudo (or su) script can be substituted for
the real sudo (or su or other auth tools) or some other script via
'alias'. Obviously, this is bad (I have a theory about the Unix
psychology behind this well-known issue) but its easily remedied by
making the init files immutable:
# Protect sh and bash init files
chfiles="/home/user/.bashrc /home/user/.bash_profile /home/user \
/.bash_login /home/user/.bash_logout /home/user/.profile"
touch $chfiles
chown -f root:root $chfiles
chattr +i $chfiles
I have put this in my Debian /etc/rc.local. Alternately, you can set
those files one time in your templates using the above sequence and VMs
that are created with that template (after that point in time) will
inherit the settings. Note that you cannot just set files that already
exist and ignore the missing ones, hence 'touch' will create the missing
ones.
This also has the nice side-effect of addressing that old cautionary
note about malware persisting through shell init scripts; it would have
to find another way which IMHO might not exist or not for very long.
--
Chris Laprise, [email protected]
https://twitter.com/ttaskett
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/585c96e6-bba0-3fd6-6a95-b8ebc2d98c40%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
