[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: Re: [qubes-devel] DispVM design decisions for Qubes 4.0
From: Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date: 2016-05-16 10:30:22
Message-ID: 20160516103022.GA7809 () work-mutt
[Download RAW message or body]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 12, 2016 at 12:13:57PM +0200, Marek Marczykowski wrote:
> Hi all,
>
> In Qubes 4.0 we're going to (finally!) implement support for multiple
> DispVM templates: https://github.com/QubesOS/qubes-issues/issues/866
>
> In principle it will be possible to start an AppVM in "disposable" mode
> - which means changes to its private image (in addition to root image as
> in normal AppVM) will be discarded after VM shutdown. Technically any
> AppVM can be used for that, but practically it makes sense to have
> dedicated "DispVM template" AppVMs (as currently fedora-xx-dvm).
>
> Since DispVM support will be basically rewritten from scratch, we may
> change some things if there is need for it. Below is some non-exhaustive
> list of things for consideration:
>
> ### 1. How to choose which DispVM should be used?
>
> For DispVM started directly from dom0 it should be easy - we may simply
> have some command line option for that (like: qvm-run --dispvm fedora-23-dvm).
> But how about DispVM started from another VM (opening some document,
> link etc)?
> I think the most straightforward solution would be to have another VM
> property: which DispVM should be used for calls from this VM (simply
> called "dispVM"). But maybe there are other ideas? For example does it
> make sense (and when?) to use different DispVM depending on what
> file/action is opened? Should it be controlled by calling VM? If so,
> should a VM be able to launch any DispVM, or only selected one (based on
> some setting and/or qrexec policy)?
>
> ### 2. What should be properties of created DispVM?
>
> Currently new DispVM inherit some properties from calling VM. Those
> properties are:
> - label
> - netvm (based on dispvm_netvm property from calling VM)
> - firewall rules
>
> Does it make sense to extend/shrink this set?
>
> The main idea behind inheriting network related properties is to prevent
> leaks from infected documents when opened in DispVM. This is especially
> important when using VMs behind Tor - you don't want to give clearnet
> access to (potentially compromised) PDF viewer, when opening some
> document downloaded anonymously over Tor, because that would leak your
> real IP address.
>
> While having multiple DispVM templates will make it possible to highly
> customized them (for example have one for each network connection), but
> I think in practice it doesn't scale well.
>
>
> ### 3. Do we need multiple ways to start DispVM?
>
> (somehow connected to previous questions)
> This has been raised in the past that it would be useful to be able to
> start networked DispVM or non-networked DispVM. For example open
> documents (run pdf converter etc) in non-networked DispVMs, but open
> links in networked DispVMs.
> Do we need anything else? Or maybe such cases can be solved by using
> different DispVM templates?
>
>
>
> In all the above cases, please provide concrete use cases and keep the
> discussion on topic. While technically many options are possible, we
> want to have the design as simple as possible. To easily (and properly)
> implement it. But also to be easy to comprehend by the users (and future
> developers). So anything that requires complex flow chart to follow is
> no-go.
>
I can see it useful for the DispVM template to be dependent on the (srcvm,
qrexec_service) tuple. E.g. I might want to open most files in a Linux-based
(Disp)VM, but for MS Office files I might want to have a special service
(qubes.OpenMsOffileFile) that would open it in a Windows-based one.
It's important that the type of the VM was enforced by the global policy, not by
the srcvm. E.g. I might _not_ want my anonymous VM to be able to start my
Windows-based (Disp)VM and learn the product key. E.g.:
cat qubes.OpenFile
anon @dispwin7 deny
$anyvm $dispvm allow
cat qubes.openMsOfficeFile
work-email @dispwin7 allow
The '@dispvm' represents a disposable VM created from the 'dispvm' template (see
[1]). For compatibility reasons we might alias $dispvm -> @(default_dist_vm).
So, I'm leaning towards changing the syntax for qrexec-client-vm (the tool we
invoke in the srcvm) to the following:
qrexec-client-vm RPC_ACTION_NAME[+ARGUMENT]
For services where the RPC precisely defines the destvm, this would be handled
according to the policy, e.g:
cat qubes.Gpg
work-email keys-itl-email allow
And for those services where the policy doesn't specify the target VM explicitly
(i.e. the 2nd argument is $anyvm, or more broadly speaking cannot be evaluated
into the specific VM in the system, which might be the case when we introduce
tags in Qubes 4), such as e.g.:
cat qubes.FileCopy
$anyvm $anyvm allow
...we would have the Dom0's qubes-rpc-multiplexer to popup a window asking
the user to provide the target VM manually (something the user is required to do
anyway for such services, only that presently the VM-side script is asking for
the target VM). For compatibilily we can allow the qrexec-client-vm to take the
targetvm argument and just ignore it (or provide as a "hint" to the Dom0-asking
program maybe?)
Generally, as discussed many times already, we should work towards having all
the inter-VM, as well as the VM-world interactions, including the networking
policy (firewall), all to be controllable by the global (qrexec) policy. These
should not be hard-coded into the qrexec mechanism.
The recent introduction of "the policy argument" [2] should make this now
possible. E.g. the networking - at some point can be replaced with
qubes.{Ip,Tcp,Udp} services. Although, I think, especially in case of
networking, we should also add a way to enforce the argument by the policy for
service requests which otherwise don't specify arguments, e.g I would like to be
able to state:
cat qubes.Tcp
work-email $netvm allow smtp.itl.com:25,imap.itl.com:993
anon whonix-gw allow # Don't allow networking through other netvms
whonix-gw $netvm allow *:https # Mostly to catch incidental bugs
@dispvm $netvm deny # 'dispvm'-based DispVMs cannot do TCP by default
$anyvm $netvm allow
cat qubes.Udp
vpn-gw $netvm allow gate.itl.com:1194 # Mostly to catch config errors
@dispvm $netvm deny # 'dispvm'-based DispVMs cannot do UDB by default
$anyvm $netvm allow
Where the '$netvm' represents the actual netvm to which the srcvm is connected
to (i.e the netvm should remain a property of the srcvm).
The above examples also suggest that DispVMs should not be implicitly inheriting
any policies from the srcvm, like it is currently the case with firewall
configuration. I think this is a cleaner approach. Although there is some
potential problem -- e.g. I might want most of the DispVMs to be offline, except
the one for opening URLs from my email domain. So I would like to say something
like:
cat qubes.Tcp
$dispvm deny
$dispvm.srcvm=work-email allow *:https # Admittedly syntax a bit clumsy...
Such central configuration of all the VM interactions from within the Qubes
policy, combined with our management framework, should make it much easier to
offer default preconfigured configurations, hopefully making it harder for
users to shoot themselves into their foot.
BTW, I think it might be useful to also provide some kind of a policy evaluation
tool, or some kind of a "simulator", to let the admins test the policies. One
example of a policy evaluation tool might be a graphing tool (based on dot) for
drawing all the allowed RPC invocations between VMs. Am I not mistaken that it
should work in O(M*N^2) time, where M is the number of files in
/etc/qubes-rpc/policy, and N is the no of VMs in the system?
The remaining questions are how to determine the DispVM's 1) label and 2) netvm?
I don't have a strong opinion here, although I'm leaning towards having the
DispVM inherit the two from its template.
joanna.
[1] https://groups.google.com/forum/#!topic/qubes-devel/uQJL7I70GQs
[2] https://www.qubes-os.org/doc/qrexec3/
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXOaE9AAoJEDOT2L8N3GcY5KAQALWTuMwAaBN7ZJaMwDvm9Cm4
6WgM6r7ghEOOw4nV1ufm/cbiqK/PFEoaYs1k0SxIDoGU5mXjAdUulcFAkNlQDr50
aq7hAko2mVWHjiSW8ohmuFQN0b/uI9eVzgMaMF8CBQmX17AbGg1oKFNykKihv/1W
hI1aBEVKHBlOpaA2E9rCOfC7EXwTA9UVEXU9KbCbkKiD+GYcg7gStZ0WSj3KQnJB
433z4jR3lt14eM+qBZLsF0NcMez0fvKBApD1zFECy/nt850EkxIBhGCcG8BrPLmm
gzsoIEqNZIqQO+fkR5pur/o8IVHWj3BMJOPABHnKgBlL3MkcJzrrgaEbjnswmO3G
hBoPbGPFeQCJaQTVl+VPh50p/iVU/wPEVZrd85bR65OzMQt3wZuNVgPNCfKTf0+S
XaTclFMg48Tf0UXezmcumhenYUDgP8ZtGucrdEPN0Hrdz7/Tg6cM8gXWBEJ6SD/x
SoqVlF96bUBxwQT6VQ5qAn99X4c+IO63Iwu0bJSTQfa67bUNOVx2Ir/N6HBoo/6W
d89h/7pMRk22WA37HgnYr6zs04lEXknISOB7heGFaWeAzyW+zWKTiF4xo77BF64a
uqYpT4o/qBFI5ZX8SKJ6479HweXktwc0MMBRJzYPm9EndJ9tvQU1P3ZYsDrg3eZC
2F7FLzkPoRlX//lPKPMy
=fwjC
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20160516103022.GA7809%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic