[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:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2016-05-16 11:57:51
Message-ID: 20160516115751.GT25975 () mail-itl
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, May 16, 2016 at 12:30:22PM +0200, Joanna Rutkowska wrote:
> 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).

I'd rather avoid another magic character here and use something more
descriptive. Like "$dispvm:dispvm" (for example: "$dispvm:fedora-23-dvm").
Then "$dispvm" would mean "default DispVM", not "any DispVM".

But, how would you decide what service should be called? I.e. when to
use qubes.openMsOfficeFile instead of qubes.OpenFile? Using some mime
handlers in the calling 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]

This is very similar to what is discussed here:
https://github.com/QubesOS/qubes-issues/issues/910

But I wouldn't remove target VM name from here. Simply pass empty string
('') as "lets dom0 decide". See below.

> 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

s/qubes-rpc-multiplexer/qrexec-policy/

> 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?)

I'd not remove an option to specify target VM name by calling party.
There are multiple cases when it makes sense. For example you can have
policy like this:

cat qubes.Gpg
devel    keys-devel  allow
release  keys-devel  allow
release  keys-release  allow

In other words: allow devel VM to access devel keys, but release VM to
allow both devel and release keys. Then have different target domain set
in different places (here: keys-devel for git and keys-release for rpm).
Asking for target VM in such a case (even with properly set default)
will be a huge UX regression...

But in case of not specified target domain, if the policy is
unambiguous, that could be used directly. If not - ask for target VM in
dom0. Probably using policy as a hint - for example:

cat qubes.FileCopy
work work-email ask
work work-web ask
work work-vault ask

Then the target VM prompt should list just those three VMs, with
'work-email' being the first one (default).

> 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

So here, the argument means "all the firewall rules, to be evaluated by
the service", not "connection target". So in this case (part of) actual
policy would be enforced by the service itself, not dom0 policy
mechanism. This is something different than policy argument was designed
for.
Also it isn't exactly what you wanted: you've written "for service
requests which otherwise don't specify arguments", but in fact you
wanted to "override regardless of argument specified by the caller".
Otherwise the called may specify its own policy, like "*:*"...

There is a also another problem with such approach - having complex argument
(like full network policy) in a single string may be hard to manage and
very error-prone. Also, currently we filter argument from almost any
non-alphanumeric characters, to ease secure service implementation (not
to worry about shell special chars, path traversal etc). If we want to
put full firewall into service argument, that would be tricky (for
example '/' and '*' are not allowed, so 1.2.3.0/24:* would not be
possible). 

Maybe better, for readability, would be to use argument as target
host:port? But then it would be even harder to specify policy like
"allow *:https", because in current approach we can either allow or deny
_specific_ argument, not some group of them based on some expression...

> 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).

Having '$netvm' which means different things depending on calling VM
may be misleading. I'd rather understand it as "system default NetVM".
Maybe "$srcvm:netvm"? Later we may introduce another options like this,
for example "$srcvm:gpgvm".

> 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...

Maybe have a separate DispVM for that? Then the syntax would be clearer:

cat qubes.Tcp
$dispvm		              deny
$dispvm:my_web_dispvm         allow *:https

cat qubes.OpenURL
work-email $dispvm:my_web_dispvm allow

Admittedly at the cost of having additional DispVM base VM to manage.

> 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/

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXObW+AAoJENuP0xzK19cs6FUH/2TrB5fyCHOklGeLeghFhyTf
x1cr9ZJxDBb3uXfKEQ1+phB1RuABR02mPQOCVtqw0kD0XUV97MUUUhedPllymAqD
ItLu1nWcY1Z84Y1GJHYV604ImcEViM4SAiYFSGoo6yTfTIva/zbxPvflT52ohffT
xnugBkTvGWOPj+SXznPpLpliElryjMZ4O4Ad4ui1vsjClfQ0QwjTGGgmSwVzA2UF
R2ZsMcLNYEMaAHgv34PM9BBD7zIQDG5MsZnVq0UZJ8DD7aE0Iy8X1+o52ttuZAZ/
q2ZptBKVYKz1ks5n3qerbgdrTYXop7y76Dshj4Ir9ZIQWgS4HOMFgIs4zxe2qtY=
=8Qrd
-----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/20160516115751.GT25975%40mail-itl. 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