On Fri, Dec 23, 2016 at 6:04 PM, Nicklaus McClendon <nickl...@kulinacs.com> wrote: > I'm intrigued. How is qrexec utilized?
Something which I have not set up yet, but intend to soon, is a split email server model, where the MTA and MDA are in separate VMs, and incoming mail is delivered over qrexec. This would have the property that an exploited SMTP server would not have any access to already-delivered mails (assuming residual message contents are not left hanging around in memory too long). Furthermore, I could have multiple separate mail-sink VMs (with local mail storage and IMAP servers), which are connected to separately via different instances of my mail client on my Qubes laptop. This means I could heuristically filter my mail based on assumed purpose (for example, mail to a qubes mailing list go to one VM, mail from my bank goes to another, etc.). This means a compromised mail client on my Qubes laptop would be restricted to only the mail that domain is expected to have, and pivoting from that compromised client to compromising my IMAP server would not be sufficient to obtain the mail from a different domain. Additionally, the usual mail pipeline suspects like spamassasin, clamav, etc. could be run in a DispVM per message (a super heavyweight solution to be sure, but should not matter for personal mail workloads on my own server). > If you can't access dom0, qrexec is default allowed, Uhh.... What? Can you elaborate? As far as I understand and can verify, this is not the case: [user@dom0 ~]$ /usr/lib/qubes/qrexec-policy --just-evaluate 56 disp8 disp9 qubes.Filecopy foo [user@dom0 ~]$ echo $? 0 [user@dom0 ~]$ DISPLAY= /usr/lib/qubes/qrexec-policy --just-evaluate 56 disp8 disp9 qubes.Filecopy foo qrexec-policy: cannot connect to X server [user@dom0 ~]$ echo $? 1 > which removes the added security of it. Definitely not entirely. > If you're remotely accessing dom0, you're adding the networking stack to the > TCB, Not necessarily. At least your NIC need not be trusted, potentially more. > and once again have a basic Xen installation with extra unnecessary overhead. ... and if overhead is your primary concern, why even bother with Xen at all? Why not use containers or such. > qrexec with a networked dom0 doesn't seem anymore secure than using SSH to > run remote scripts between networked VMs. Assuming you mean SSH between the VMs, I'm not sure I agree. Networking has a much larger attack surface, and you are relying on crypto with keys that can be stolen rather than vchan where the authenticity of source and dest and integrity of msg contents are already trusted. OTOH, OpenSSH has a pretty stellar track record and has likely received more scrutiny than vchan (which I have not audited myself yet either), so I can certainly understand the contrary argument too. -- 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/CABQWM_B8-NH1Da3S%2BLu0bhAZhp_vnUNsL-bLK_A2HHOaUykFzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
