Added qubes-devel to CC rather BCC, sending in plaintext :)

On 05/30/14 14:46, Joanna Rutkowska wrote:
> Moving to qubes-devel, please respond there.
>
> On 05/29/14 13:38, Marek Marczykowski-Górecki wrote:
>> On 29.05.2014 12:17, Joonas Lehtonen wrote:
>>> Hi,
>>>
>>> what do you think about using qubes-vm-types as placeholders for
>>> src/dstvm policy entries?
>>>
>>>
>>> Lets say I want to be asked for confirmation if an AppVM wants to
>>> execute something on another AppVM, but I don't want to be tricked
>>> into allowing (by clicking 'Yes') any AppVM -> TemplateVM, or AppVM ->
>>> ProxyVM excution paths. They are potentially dangerous and any AppVM
>>> -> TemplateVM should be discarded - to safe the user from himself ;)
>>>
>>>
>>> Furthermore one might like to allow only AppVMs to create disposable
>>> VMs and to deny disposable VMs from creating new ones.
>>>
>>> The hypotetical ruleset would then look like:
>>>
>>>
>>> $AppVM $createdispvm allow
>>> $AppVM $AppVM ask
>>> $DisposableVM $createdispvm deny  // this line can be omitted
>>> $anyvm $anyvm deny
>>>
>>>
>>> To be honest the current vm-type names are quite long to type ;)
>>>
>>>
>>> Note: I used $DisposableVM (does not currently exist) and not $dispvm,
>>> since according to the updated documentation [1] $dispvm does not
>>> actually mean 'a wildcard for all disposableVMs' but it rather defines
>>> an action (create a new dispvm) - which is why I renamed it to
>>> $createdispvm in the fictive ruleset.
>>
>> Generally it is a good idea, current policy syntax isn't as flexible as one
>> might want. The other think is setting policy based on VM label - for example
>> disallow copying data from "red" VMs to "green" (there was a discussion about
>> this on qubes-devel few years ago).
>> One possible technical problem here is performance - policy evaluation need to
>> be fast (for example it is happening when one press Ctrl-Shift-V), but loading
>> is time-consuming (~200ms currently on system with ~40 VMs). This can be
>> solved by having some daemon, which will hold the database loaded and will
>> evaluate policy requests. In other words: this isn't easy, but doable and we
>> may put this on R3 roadmap.
>>
>
> On 05/29/14 15:06, Joonas Lehtonen wrote:
>> Another nice feature would be simple regex based matching like:
>>
>> foo* $anyvm deny
>>
>> to prevent all VMs whose name starts with "foo" to do anything.
>>
>> Not something that would make policy matching faster but still a nice
>> to have feature to keep policys short and readable.
>>
>
> I don't like the idea with using the VM type as a policy parameter,
> because it is *not* meant to reflect the "security/trust level" of the
> VM in question. We have a special property in Qubes that is specifically
> allocated for this purpose and this is the VM color label.
>
> So, I like the idea of using the vm names and labels (as Marek wrote
> above) in the policy definitions, but not vm types.
>
> The regexp-based rules (but only expanding to vm names, not labels!)
> might be a good idea, although I'm worrying a bit that they might easily
> lead to situations when the user shoots themselves in the foot, simply
> because the regexp is to be expanded differently than the user expect, a
> popular problem with advanced regexp usage (Happens to me all the time
> when I use grep or sed ;) So this really would need to be "simple" regexp...
>
> I'm thinking whether vm name and label will be "enough for everybody" or
> should we consider introduction of also additional properties to VMs?
> Perhaps user definable properties? E.g.:
>
> qvm-prefs work -s corporate
> qvm-prefs accounting -s corporate
>
> And then in the policy (e.g. qubes.ClipboardPaste):
>
> $property:corporate $property:corporate allow
> $property:corporate $anyvm deny
>
> joanna.
>

On 30/05/14 13:48, Joanna Rutkowska wrote:
>> I'm thinking whether vm name and label will be "enough for
>> everybody" or should we consider introduction of also additional
>> properties to VMs? Perhaps user definable properties? E.g.:

I really like this idea. It is simple and flexible, assuming the user
can assign more than one tag to a VM. One could also have a Qubes
reserved tag namespace, which could include a "running" tag only if
the VM is running (could be used to differentiate between new dispvms
and already running ones, for dispvms having otherwise identical tag
sets).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> I don't like the idea with using the VM type as a policy
> parameter,
>> because it is *not* meant to reflect the "security/trust level"
>> of the VM in question. We have a special property in Qubes that
>> is specifically allocated for this purpose and this is the VM
>> color label.

While I do not agree completely, because vm-types have some implicit
trust values assigned to them (i.e. templateVM vs. disposableVMs) the
properties based (something I had in mind as well) is anyway better
and would make type-based rules obsolete anyway.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTiRuBAAoJEG58zmw5nc+vFZ0P/RFFrGB/ytqKrXM1y30b0SEv
/dtERbr96s0BsgsAlm525UWTfhdW7EM6OdUQPLNiFSQWtjhBOfZvtFosnb0XyUu1
nLU3Ck55GVwFp8T5EH/APpVuOBj/SYSldlgRle7S2t5Uja9yUzi2q4ywPulDD7hH
ZWRZV77KcEO7UD7vuzDHKh0PCwmOg6oh3BoLfjkqpIy51ysSq0rvpN6e6Ivw9dBd
MPz9WiOt0LP1OmpjpRk6ISaXtvycaaQabnRTv6l4ldHmsLuo/cF0kgGFGklpZ3E2
IQhTi+BwwUGGbWb/gMstW3QA1O3XQgk53SdE6kFw+fWeZ7c3EQ2ytZ4OPIeE5pz7
q38C5kLQZvWrg0zuixf8EMX/bKiUPhWyonIJUnlzEPAeS96XogZD8/a43O6NvUVZ
0WvoXHyGbc9y8o/8Yfq8nYTN23Uojaee4m1tfH5Rkky7cyj0ou/DXh31o45fnvsZ
Up6FlzU9jjwi4RZIiEHGR0ffU/eU9RwcvRmcz+T5oEmEEo0f2W56h1OzVOg9eaw/
YnyMH090t9DRp7wbcgqEDKCqb8Cv1Y02CIpvvLAuQ5gklfE5XPEC4hZo5WqG0zJo
UHJHrITAn/dqI+nWcLSn0Jvc7UMN4uTrT46Y9jUmAQiykcjFLXI+74Ovh+G+W0K1
Oulm8l6GFAE4v++bQNGT
=Fde1
-----END PGP SIGNATURE-----

VM tags might also be handy for other tasks -- e.g. 3rd party tools
might be able to e.g. backup only VMs with a specific tag defined, etc.

So, considering a VM in Qubes, we can see a few namespaces:

1) the VM name namespace (e.g. "work")
2) the labels namespace (red, yellow, green, etc)
3) the user-assignable tags or attributes
4) the Qubes internal attributes (as displayed currently by qvm-prefs),
which includes both user-settable ones, as well as read-only ones (e.g.
state)

Some questions:

1) Do we want to somehow unify the above? This might include unification
for how we store those tags/attributes internally in classes, as well as
unification from the user point of view (should we introduce new
commands/API like qvm-tag)?

E.g. VM labels (#2) might be a special case of user-assignable tags or
attributes (#3)

2) Do we want to let the user assign tags or attributes (= a tag with a
value)?

joanna.

On 05/31/14 02:00, Joonas Lehtonen wrote:
>> I don't like the idea with using the VM type as a policy
>> parameter,
>>> because it is *not* meant to reflect the "security/trust level"
>>> of the VM in question. We have a special property in Qubes that
>>> is specifically allocated for this purpose and this is the VM
>>> color label.
>
> While I do not agree completely, because vm-types have some implicit
> trust values assigned to them (i.e. templateVM vs. disposableVMs) the
> properties based (something I had in mind as well) is anyway better
> and would make type-based rules obsolete anyway.
>

Scheduled for R3:

http://wiki.qubes-os.org/trac/ticket/865
http://wiki.qubes-os.org/trac/ticket/867

joanna.

I'm not sure if this is already covered by the referenced ticket #853, but ticket #867 should include 'pcidevs'.
I'm playing with a prototype 'system architect' for Qubes; unifying all these parameters into one class would make my life a lot easier.

1) Yes, and yes.
2) I don't see why not, other than potential parsing issues in the tools (I don't think this changes the security model at all) or conflicts where third-party tools assign different semantics to the same attributes.

Andrew

On 02.06.2014 14:44, Joanna Rutkowska wrote:
> On 05/30/14 15:05, Vincent Penquerc'h wrote:
>> On 30/05/14 13:48, Joanna Rutkowska wrote:
>>>> I'm thinking whether vm name and label will be "enough for
>>>> everybody" or should we consider introduction of also additional
>>>> properties to VMs? Perhaps user definable properties? E.g.:
>>
>> I really like this idea. It is simple and flexible, assuming the user
>> can assign more than one tag to a VM. One could also have a Qubes
>> reserved tag namespace, which could include a "running" tag only if
>> the VM is running (could be used to differentiate between new dispvms
>> and already running ones, for dispvms having otherwise identical tag
>> sets).
>>
>
> VM tags might also be handy for other tasks -- e.g. 3rd party tools
> might be able to e.g. backup only VMs with a specific tag defined, etc.

Currently there is a way to write plugin, which introduce additional VM
attributes. Appmenus handling is done that way for example. But it is far from
ideal.

> So, considering a VM in Qubes, we can see a few namespaces:
>
> 1) the VM name namespace (e.g. "work")
> 2) the labels namespace (red, yellow, green, etc)
> 3) the user-assignable tags or attributes
> 4) the Qubes internal attributes (as displayed currently by qvm-prefs),
> which includes both user-settable ones, as well as read-only ones (e.g.
> state)
>
> Some questions:
>
> 1) Do we want to somehow unify the above? This might include unification
> for how we store those tags/attributes internally in classes, as well as
> unification from the user point of view (should we introduce new
> commands/API like qvm-tag)?
>
> E.g. VM labels (#2) might be a special case of user-assignable tags or
> attributes (#3)

I would not mix "tags/attributes" (like label, name) with "settings/runtime
info" (like template, netvm, kernel, state, disk usage). Also when introducing
user-settable attributes, IMO every such attribute should be somewhere
defined, including allowed values (if we choose attributes over tags). IOW no
free-style attributes. Otherwise it would be very easy to make a typo, which
would have fatal security consequence. Also user-defined attributes should
have somewhow separated namespace (to not conflict with possible future
Qubes-defined ones). Common practice is force user-defined properties to have
"X-" prefix - IMO it is a good idea here.
BTW Current qubes-rpc policies have this problem - user have no easy way to
validate it after editing. So errors like typos in VM name can be very easily
unnoticed.

But some unification would be helpful. Problems with current configuration:
1. it is spread on multiple locations (qubes.xml, firewall.xml, guid.conf,
/etc/qubes-rpc/policy etc),
2. different configuration formats, naming schemes,
3. qubes.xml parsing is very complex (this is one of main reasons why some
configuration is kept outside of it),
4. qubes.xml layout is ugly - all VM settings in attributes (not child
entries), flat structure, all VMs directly under root element, global settings
in root element attributes and many many more,
5. there is no easy way to notice what was changed when qubes.xml got updated
- especially painful for Qubes Manager, which currently need to reload all the
VMs when one attribute was changed.

I think qubes.xml should be completely redesigned from scratch to solve above
problems (perhaps not even XML based? to solve fifth problem). IMO we should
first work out some initial version internally and only then possibly start
discussion about it on qubes-devel (with some starting point). Otherwise the
discussion will be very long and mostly unproductive...

> 2) Do we want to let the user assign tags or attributes (= a tag with a
> value)?

If attributes at all, only with predefined allowed values, which BTW can be
done with tags - instead of attribute "x-security-level=high" one can use tag
"x-security-level-high". The only difference would be forcing only one value
of given attribute at once (so tag "x-security-level-high" would be mutually
exclusive with tag "x-security-level-low").

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