RFC: On Colors, Trust Levels, Data and Control Flows between domains
Joanna Rutkowska
As you know each domain in Qubes is labeled with a color, which
currently is just an arbitrary marker that helps the user to easily
distinguish between windows belonging to different domains. Currently
Qubes doesn't interpret the label color in any way, so some users might
decide to use red to label their untrusted domains, while some other
users might use it in an exactly the opposite way.
However, I've recently become more and more convinced that Qubes should
start interpreting those colors as actual trust levels and use this e.g.
for controlling the inter-domain data transfers.
This would allow for a few nifty features:
1) Qubes could *always* display a scary warning whenever the user
attempts to copy clipboard or files from a *less* trusted to a *more*
trusted domain (see [1] for more explanations on this). Of course, the
user should be able to confirm this operation and proceed with it.
1a) In the future we might pass data through some trusted converters, if
the flow goes from less-to-more trusted domains (see [1] again).
2) If the user attempts to copy from a *more* trusted to a *less*
trusted domain (or between two with the same trust level), the Qubes
should ask for confirmation first (without displaying a _scary_
warning), but might also offer an "always allow" option, which would
allow for further transfers between those two domains to not require
explicit confirmation.
3) The above mechanisms could also be extended to allow some domains to
delegate some mime actions, such as opening an URL, to other, less
trusted domains. As suggested by Gynvael recently, it would be handy if
I could make e.g my 'work' domain to automatically open URLs that I get
over email, in my 'red' domain. We might provide special mime handler in
AppVMs that would be indicating the required action over xenstore/vchan
to the corresponding qrexec daemon.
4) it might also be advantageous to label templates with a trust level,
and then to require that each AppVM couldn't be assigned a higher trust
level than the template that it is based on. A practical example: I have
cloned the default template that comes with Beta 1 and created a
fedora-14-x64-yellow template (via qvm-clone-template). Then I have
installed a bunch of 3rd party RPMs there, such as some video
codecs/software, unsigned printer drivers I found on some website, etc.
All this 3rd party software might have been somehow malicious,
specifically the installation scripts might have compromised the
template, so I consider it only moderately-trusted ("yellow"). Now, it's
not a problem for me to create a bunch of other moderately-trusted
domains on it, such as e.g. 'personal', 'work-pub', or 'red'. But I
would like to make sure that I won't accidentally create any domain for
some more trusted activities (e.g. for some work project), based on this
semi-trusted template.
So, let's now talk about how I would like that we reuse colors to
actually mean trust levels. Of course, one could say that we might just
introduce another attribute for domains, i.e. the trust level, instead
of reusing the color labels, but I think this would be a wrong path,
because:
1) This would complicate things -- we already have two attributes per
each domain, i.e. the name and the color. Why introduce another one?
2) Colors are easily noticeable markers on the desktop. I would argue
that nothing can compete with a titlebar/border coloring in terms of
being easily spottable. So, it seems logical to interpret them as
security trust levels (user sees red border and knows no sensitive stuff
should be done inside!)
So, I think re-using colors as trust level indicators should be a
no-brainer. However, I would like to go even further and suggest that we
fix the meaning of colors, somehow like this:
* red <-- untrusted
* yellow <-- somehow trusted, not very sensitive
* green <-- trusted, sensitive
* blue <-- very trusted, very sensitive
Yup, just 4 levels. Should be enough for everybody :)
I expect that some Linux purist would be advocating that we should allow
a config option that would let user to: 1) map trust levels to colors,
2) use RGB-defined colors, 3) use arbitrary number of colors/levels
But I personally don't like such an idea -- from my experience in
observing *normal* people in their natural habitats, people get lost if
one offers them too many config options. They would be overwhelmed.
Additionally, because interpretation of colors is such a
security-critical thing ("I do sensitive things only in green or blue, I
do dangerous things in red") I think it would be easier if this was just
fixed. We could easily teach users analogies to the real life: "red
light -- danger, don't go!", "green light -- safe", "yellow -- somehow
dangerous".
What do you think?
Back to trust levels and data/action between domains. It might be
tempting to always allow copy/mime open when the operation originates
from more trusted to less trusted domains. But, I think this would be a
mistake, because not all domains should be in direct trust relation
between each other. Example: I might not want to automatically allow my
work domain (green) to request URLs opening in my personal domain
(yellow). Thus we should always ask for permission for the first time,
but offer an "always allow" option in case of down-transfers (or no-up).
Looking forward to your comments/other ideas.
Cheers,
joanna.
[1]
http://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html
Bryce Lynch
<joa...@invisiblethingslab.com> wrote:
> As you know each domain in Qubes is labeled with a color, which
> currently is just an arbitrary marker that helps the user to easily
> distinguish between windows belonging to different domains. Currently
> Qubes doesn't interpret the label color in any way, so some users might
> decide to use red to label their untrusted domains, while some other
> users might use it in an exactly the opposite way.
For those of us who are color-blind, would there be an option for
picking different patterns rather than colors to differentiate VMs,
such as horizontally striped window bars vs. vertically striped window
bars, vs. bars with solid coloration...?
--
The Doctor [412/724/301/703]
http://drwho.virtadpt.net/
"I am everywhere."
Joanna Rutkowska
If somebody submits code for doing this (proper window decorator
plugin), then probably yes. Otherwise we won't probably have resources
to work on this.
So, this might actually be an argument for allowing some kind of
"advanced" tinkering option to actually let the user map trust levels
onto "colors/patterns"... Hm...
j.
Radoslaw Szkodzinski
That and color assignments are clearly western culture-centric.
Other cultures might associate the colors differently.
Radoslaw Szkodzinski
<joa...@invisiblethingslab.com> wrote:
> Hello,
>
> As you know each domain in Qubes is labeled with a color, which
> currently is just an arbitrary marker that helps the user to easily
> distinguish between windows belonging to different domains. Currently
> Qubes doesn't interpret the label color in any way, so some users might
> decide to use red to label their untrusted domains, while some other
> users might use it in an exactly the opposite way.
>
> However, I've recently become more and more convinced that Qubes should
> start interpreting those colors as actual trust levels and use this e.g.
> for controlling the inter-domain data transfers.
> <reordered for readability>
> All this 3rd party software might have been somehow malicious,
> specifically the installation scripts might have compromised the
> template, so I consider it only moderately-trusted ("yellow"). Now, it's
> not a problem for me to create a bunch of other moderately-trusted
> domains on it, such as e.g. 'personal', 'work-pub', or 'red'. But I
> would like to make sure that I won't accidentally create any domain for
> some more trusted activities (e.g. for some work project), based on this
> semi-trusted template.
Hmm, why would you want any less than trusted template available by
default anyway? What kind of ease of use does this bring?
This behavior would only make sense for user-created templates.
Bottom line: Better just have a few simple basic ones and allow user
to easily convert a running modified system into a template, like a
snapshot.
> So, let's now talk about how I would like that we reuse colors to
> actually mean trust levels. Of course, one could say that we might just
> introduce another attribute for domains, i.e. the trust level, instead
> of reusing the color labels, but I think this would be a wrong path,
> because:
>
> 1) This would complicate things -- we already have two attributes per
> each domain, i.e. the name and the color. Why introduce another one?
A simple number is not expressive enough - a set based approach like
ACL is likely better for advanced configuration.
The notion of levels is pretty bad on its own - real security needs
more special cases.
Useful abstraction for an overview though - that's the job the colors
are suited for.
> 2) Colors are easily noticeable markers on the desktop. I would argue
> that nothing can compete with a titlebar/border coloring in terms of
> being easily spottable. So, it seems logical to interpret them as
> security trust levels (user sees red border and knows no sensitive stuff
> should be done inside!)
Window labels, patterns and icon overlays (for icons, where
applicable) are quite competitive in my opinion.
Especially striped patterns - they're used by nature to designate danger. :)
> So, I think re-using colors as trust level indicators should be a
> no-brainer. However, I would like to go even further and suggest that we
> fix the meaning of colors, somehow like this:
>
> * red <-- untrusted
> * yellow <-- somehow trusted, not very sensitive
> * green <-- trusted, sensitive
> * blue <-- very trusted, very sensitive
>
> Yup, just 4 levels. Should be enough for everybody :)
You mean at least 5 - there's also Dom0 (silver).
I like to have an "orange" level somewhere inbetween red and yellow,
for "uncontrolled" or "unknown" (somewhat untrusted) level and make
that the really default one.
Similar to "untrusted", but with fewer scary messages perhaps.
Oh, and some level for system services which are separately
virtualized - e.g. if someone puts pulseaudio and its volume control
in another ServiceVM, some windows will be shown.
Perhaps white? It's like green/blue, but system-critical, possibly
directly externally accessible and shouldn't support most kinds of
interaction with the desktop environment.
Somewhat a "system trusted" level. Similarly, a black (dark gray)
level for "system security". Keep the gray/silver for generic Dom0.
> I expect that some Linux purist would be advocating that we should allow
> a config option that would let user to: 1) map trust levels to colors,
> 2) use RGB-defined colors, 3) use arbitrary number of colors/levels
>
> But I personally don't like such an idea -- from my experience in
> observing *normal* people in their natural habitats, people get lost if
> one offers them too many config options. They would be overwhelmed.
Correct, but only if the options are shown by default. Have an
"Advanced" or "Edit security profiles" button in options like in
Windows,
provide reasonable defaults and you're set. Don't go the Gnome way of
cutting options for the sake of simplicity - it penalizes power users
and developers.
Basic options should have the profile choice and perhaps "Network" and
"Clipboard" checkboxes.
Advanced options could provide a way to construct your own security
profile more tailored to your needs, and perhaps combine them if
necessary.
> Additionally, because interpretation of colors is such a
> security-critical thing ("I do sensitive things only in green or blue, I
> do dangerous things in red") I think it would be easier if this was just
> fixed. We could easily teach users analogies to the real life: "red
> light -- danger, don't go!", "green light -- safe", "yellow -- somehow
> dangerous".
>
> What do you think?
That's the "reasonable defaults" part. But in my opinion, again, it
should be the trust level (profile) name being the more important
thing than color.
> Back to trust levels and data/action between domains. It might be
> tempting to always allow copy/mime open when the operation originates
> from more trusted to less trusted domains. But, I think this would be a
> mistake, because not all domains should be in direct trust relation
> between each other. Example: I might not want to automatically allow my
> work domain (green) to request URLs opening in my personal domain
> (yellow). Thus we should always ask for permission for the first time,
> but offer an "always allow" option in case of down-transfers (or no-up).
In any case, some kind of scrubbing and preview will be necessary -
quite a bit of work to do.
User clicking "always allow" is pretty bad for higher untrusted levels
(orange and red) and breeds bad habits.
Better to have this separately configurable, so that users don't learn
the wrong approach to dialog windows.
> <reordered for readability>
> This would allow for a few nifty features:
>
> 1) Qubes could *always* display a scary warning whenever the user
> attempts to copy clipboard or files from a *less* trusted to a *more*
> trusted domain (see [1] for more explanations on this). Of course, the
> user should be able to confirm this operation and proceed with it.
Perhaps have a sudo-like time limit behavior for copies from one
window to another to avoid being swamped by dialogs.
If I pasted an url from my text editor to web browser, it's pretty
safe to assume I could do that 15 minutes later too.
But *only* for those two windows - and the right cooldown has to be
established, as well as automatically cleaning those on screensaver
for example.
> 1a) In the future we might pass data through some trusted converters, if
> the flow goes from less-to-more trusted domains (see [1] again).
Good idea. Leave some hooks for virus/exploit scanners while you're at
it, please, so that the converters don't have to be abused for this
purpose.
Multilayer defense is nice to have.
> 2) If the user attempts to copy from a *more* trusted to a *less*
> trusted domain (or between two with the same trust level), the Qubes
> should ask for confirmation first (without displaying a _scary_
> warning), but might also offer an "always allow" option, which would
> allow for further transfers between those two domains to not require
> explicit confirmation.
+1, but don't put this option in the dialog window. It's far too
tempting to click for many and obviously voids most of security
separation.
Instead, put that in options with many disclaimers. ;)
> 3) The above mechanisms could also be extended to allow some domains to
> delegate some mime actions, such as opening an URL, to other, less
> trusted domains. As suggested by Gynvael recently, it would be handy if
> I could make e.g my 'work' domain to automatically open URLs that I get
> over email, in my 'red' domain. We might provide special mime handler in
> AppVMs that would be indicating the required action over xenstore/vchan
> to the corresponding qrexec daemon.
It's RPC with another name. Very useful, but the daemon must be pretty
secure and security policy expressive enough without being too hard to
work with.
I've commented about the design of such ACL before. Netfilter-like
rules (without the silly command line tool) are simple enough and
expressive.
> 4) it might also be advantageous to label templates with a trust level,
> and then to require that each AppVM couldn't be assigned a higher trust
> level than the template that it is based on. A practical example: I have
> cloned the default template that comes with Beta 1 and created a
> fedora-14-x64-yellow template (via qvm-clone-template). Then I have
> installed a bunch of 3rd party RPMs there, such as some video
> codecs/software, unsigned printer drivers I found on some website, etc.
That's the use case for the "uncontrolled" orange level. You mostly
know what's there, but don't necessarily trust everything.
The default Linux security trust level. "Untrusted" would be a more
restrictive variant of this.
But do allow an advanced user to override this template security level
- this might allow for easier construction of dependent templates.
Radosław
Laszlo Zrubecz
> So, I think re-using colors as trust level indicators should be a
> no-brainer. However, I would like to go even further and suggest that we
> fix the meaning of colors, somehow like this:
>
> * red <-- untrusted
> * yellow <-- somehow trusted, not very sensitive
> * green <-- trusted, sensitive
> * blue <-- very trusted, very sensitive
>
> Yup, just 4 levels. Should be enough for everybody :)
Just like 640kb of memory? :P
As I see the coloured borders are fine to identify windows of different VM's.
But If you say colour=trust level:
- How will you identify VMs?
- what if you have two yellow VM, and you run a browser from each of
the yellows?? how do you know witch one is belongs to witch VM?
I think colours should be unique and it's should be a only visual mark
for a VM.
We also need a trust level for each VM and it's should be changeable
by the user at any time... And this trust level should be visible as a
window decoration, like the 'very useful' SSL logos today :)
--
Zrubi
Joanna Rutkowska
> On 25 April 2011 13:30, Joanna Rutkowska <joa...@invisiblethingslab.com> wrote:
>> So, I think re-using colors as trust level indicators should be a
>> no-brainer. However, I would like to go even further and suggest that we
>> fix the meaning of colors, somehow like this:
>>
>> * red <-- untrusted
>> * yellow <-- somehow trusted, not very sensitive
>> * green <-- trusted, sensitive
>> * blue <-- very trusted, very sensitive
>>
>> Yup, just 4 levels. Should be enough for everybody :)
>
> Just like 640kb of memory? :P
>
> As I see the coloured borders are fine to identify windows of different VM's.
>
> But If you say colour=trust level:
> - How will you identify VMs?
> - what if you have two yellow VM, and you run a browser from each of
> the yellows?? how do you know witch one is belongs to witch VM?
>
titlebar in square brackets, in bold.
j.
David Schissler
2) If the user attempts to copy from a *more* trusted to a *less*
trusted domain (or between two with the same trust level), the Qubes
should ask for confirmation first (without displaying a _scary_
warning), but might also offer an "always allow" option, which would
allow for further transfers between those two domains to not require
explicit confirmation.
I think that it would be very nice if two non-red, same-color AppVMs could have their clipboards "bonded" so that when one VM copies to the clipboard it also initiates a copy to all of the other VMs that are "bonded". Perhaps this could be limited to only non-red VMs of the same trust level to prevent a breakdown of security. It could also present a rather large warning message about the dangers. I dream of being able to bond two VMs together so that I can use one for tools and another for services when Merek is able to make a plethora of templates.
3) The above mechanisms could also be extended to allow some domains to
delegate some mime actions, such as opening an URL, to other, less
trusted domains. As suggested by Gynvael recently, it would be handy if
I could make e.g my 'work' domain to automatically open URLs that I get
over email, in my 'red' domain. We might provide special mime handler in
AppVMs that would be indicating the required action over xenstore/vchan
to the corresponding qrexec daemon.
I've only used Qubes for a total of two days and I already got myself into trouble my clicking on a link in my yellow thunderbird domain. Of course it opened up the link in that AppVM/domain and I instantly said "oops". It didn't take me long to break the point on this domain.
Axon
such that your "yellow thunderbird domain," which I presume is some kind
of email domain, can communicate only with your email servers. This way,
an accidental click on a link won't really do anything.
In the case of domains which are used for both browsing and email, it's
often (but not always) worth it to decompose the two activities into
separate domains.
David Schissler
I'm considering setting /etc/rc.local to remove firefox and replacing it with a script to ssh into a red domain, export DISP and then to run firefox with the -new-tab option. I think that it will work perfectly if Firefox is already open on that AppVM, which isn't much of an issue considering that I will literally start that AppVM by running Firefox. This project is just right to practice hooking everything up.
Marek Marczykowski-Górecki
--
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?
David Schissler
Okay thanks. I'm confused in this line if this is a list of VMs that can be invoked or if it is Source and Target.
http://wiki.qubes-os.org/trac/wiki/Qrexec
policy file in dom0 ( /etc/qubes_rpc/policy/test.Add )
$anyvm $anyvm ask
I'm not running Qubes now so I have to guess as to how it all fits together exactly. I think that I understand the qrexec wiki example but I'm unsure how how the security policy would be set in your script.
Also does OpenInVM invoke xdg-open?
Marek Marczykowski-Górecki
>
>
> On Saturday, January 18, 2014 12:43:59 AM UTC+1, Marek Marczykowski-Górecki
> wrote:
>>
>> On 17.01.2014 23:42, David Schissler wrote:
>>> I'm considering setting /etc/rc.local to remove firefox and replacing it
>>> with a script to ssh into a red domain, export DISP and then to run
>> firefox
>>> with the -new-tab option. I think that it will work perfectly if
>> Firefox
>>> is already open on that AppVM, which isn't much of an issue considering
>>> that I will literally start that AppVM by running Firefox. This project
>> is
>>> just right to practice hooking everything up.
>>
>> ssh?! You have qvm-open-in-vm for this already.
>>
>
> be invoked or if it is Source and Target.
> http://wiki.qubes-os.org/trac/wiki/Qrexec
>
>
> $anyvm $anyvm ask
source target action
>
>
> I'm not running Qubes now so I have to guess as to how it all fits together exactly. I think that I understand the qrexec wiki example but I'm unsure how how the security policy would be set in your script.
>
> Also does OpenInVM invoke xdg-open?
html file, which will redirect to the destination address, so you can just use:
qvm-open-in-vm untrusted http://google.com/