On 08/29/2017 03:54 AM, pixel fairy wrote:
On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote:
The question as always is, what are you protecting? If it's your user data,
compartmentalize differently. If it's some kind of root privilege escalation,
that's a lost cause, as the vm sudo page explains. If it's some kind of malware
that could get written with root privileges, well, that gets erased by
rebooting the VM, unless it's persistent in your user data, but if it is, it's
incredibly unlikely to be runable (at least not without explicit user action).
I raise these questions because the answer to many of the "OMGWTFBBQ passwordless sudo" threads
that appear every so often, come back down to either "whatever you're proposing wouldn't make a
difference read the doc again" and "are you sure you read the doc and understood why the decision
was made the way it was?"
I believe the direction of the recurring discussion has been following a
somewhat different arc. Joanna and Marek have lately been receptive
(even supportive) to internal domU security... at least ways to enable
it. I think the impetus for the shift boils down to these points:
1. VMs shouldn't passively amass malware, even if its not a threat to
Xen isolation; its a nuisance at best that can affect other
computers/devices. DispVMs help in prevention, but not for many normal
PC usage scenarios.
2. DomU OS's have unobtrusive security features ready for use with
little or no burden to us:
With 'vmsudo' auth prompts configured, using basic domU security is very
easy: Say yes/no to the prompt shown in dom0. This is not about
passwords in AppVMs.
3. Such domU defenses, while judged to be inferior in general, do
receive patches and could allow Qubes systems to thwart attacks
ultimately aimed at the hypervisor. This matters even if Linux, etc.
remains "swiss cheese" and saves our bacon in only a small percentage of
scenarios.
4. Qubes' read-only templates provide a basis for anti-threat
persistence measures like 'Qubes-VM-hardening'[1], but only if domU auth
is enabled.
5. Xen security was not quite as good as was hoped.
Guest OS's supposedly compete on the basis of security, so its probably
best to let them do their job in this regard. Especially if all that
requires from us is to not switch off security or a little bit of PAM
configuration.
this wasnt specifically because of the passwordless sudo. its a general access
control and hardening thing. i see firejail as complementary to qubes-os. ssh
shouldnt access the x server. firefox shouldnt write outside of its own folder
and Downloads. neither should shell out and call sudo. when they do, or try to,
id really like to know about it. firejail can log such access, and you can have
another process follow that log to alert you.
but having firejail do that, and watching that log, are more processes, more
attack surface.
to add to extremely unlikely, ive only known of one ssh client exploit in the
wild, and i think it was over 10 years ago.
FWIW, AppArmor does work with Qubes VMs and doesn't revolve around a
special launcher.
[1] https://github.com/tasket/Qubes-VM-hardening/tree/systemd
--
Chris Laprise, tas...@posteo.net
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/378ae919-6e19-16bd-58de-205093399c27%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
