-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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-----