RFC: Qubes user architecture

[cubem...@gmail.com]

Hello,
   I've been spending time rearranging my Qubes desktop architecture - which VM's I want (personal, business, tor, Whonix, etc) and their relationships to each other. After much experimentation it's clear that while the actual setup will be specific to the individual, I think there is a common architecture that can be found across most use cases. At least it would be useful if had a standard for which types of VM's had which colors. With that I'd like to propose a schema for comment, and then put my money where my mouth is and offer to implement it

   Assumptions
       - Different VM's of the same color should have equivalent security

           Without this requirement using colors in the first
           place is useless! Users need to be conditioned to recognize that
           Green means "mostly safe" while Red means "mostly unsafe", for
           example

        - Data flows needs to be bi-directional - and that's OK!

           Truly one directional 'vaults' are useless. Even 'closed wall'
           top security installations have two way information flow - people
           (with sufficient clearance) go in and out. This shows that data can
           flow both directions, as long as it's controlled. Likewise, we can imagine
           an ultra-secure "secure-keys" black vault, unconnected to any
           networking with data flow out in the form of keys or encrypted
           data.

        - Data flow should be inherent by the design

           More secure VM's should only have data pipes from less secure
           VM's

    - The architecture should mirror the color priority

          That means that Red is insecure and black is totally secure (as secure as we can make it!)

    - There are two main use cases, average and advanced user

          KISS


With that out of the way let me propose a possible solution. Consider a structure such as this, for the advanced user

• Advanced Architecture
  DMZ (networking, USB, SDCard, etc)
• Red
• Orange
• Yellow
  Sandbox
  
• Green
• Grey
• Blue
  Secured
  
• Purple
• Black
  
• Special
  

The "Special" category (no color) includes dom0 and the templates (fedora-21). Assuming this, we can simplify it but keep the same structure for the average user

• Advanced Architecture
  System I/O (networking, USB, SDCard, etc)
• Red
  Sandbox
  
• Green
  Secured
  
• Black
  
• Special
  

Now what VM's would go where, given our assumptions. By example we can imagine the following setup, the item in parenthesis is the vm that feeds this one with data through some Qubes mechanism

• Advanced Architecture
  System I/O (networking, USB, SDCard, etc)
• Red
  sys-net (eth0)
  usbvm (USB)
  pentest-wifi
  playpen
  
• Orange
  sys-firewall (sys-net)
  snort (sys-net) (snort traffic analyzer - used offline for attack/intrusion analysis)
  
• Yellow
  sys-whonix (sys-firewall)
  social-networking (sys-firewall)
  sanitizer* (sys-firewall) a filter proxy for cleaning PDF's, JPG exif, etc
  
  Sandbox
  
• Green
  whonix (sys-whonix)
  sanitized (sanitizer)
  
• Grey
  work (sanitized)
  banking (sanitized)
  
• Blue
  docstorage (by inspection - hand copied from other VM's)
  
  Secured
  
• Purple
  papers (docstorage)
  
• Black
  vault (only out data flows, no in)
  
  
• Special
  ...
  

* The sanitizer is an example of a new type of VM. Johanna wrote a blog entry about sanitizing, but thought that it would be too difficult to have automatic sanitizers. I wonder though, it doesn't seem too much to imagine a tool consisting of a set of scripts to sanitize mime types that come in.

The simple use case should be clear, just take the Red, Green and Black categories,

• Red
  sys-net
  usbvm
  sys-firewall
  
• Green
  banking (sys-firewall)
  personal (sys-firewall)
  
• Black
  vault
  

Summary

   The idea is to have a design standard following a layered approach. While users will always be free to create whatever structure they want, most will probably fall into whatever design guidelines the project has. This is one logical proposal for such a guideline, deriving from the assumptions given above.

Thoughts?

[cubem...@gmail.com]

Correction, I can see already that a more natural order, for both teh VM Manager (sort on color) and the Application Launcher menu is the reverse. The most used and most secure at the top, with the least secure/least used at the bottom.

Also, I should note the motivation for this. As I've been setting up my VM's the color scheme has been chaotic! Whonix has one standard, Johanna has different examples, the default templates have another. And changing colors is a pain, the VM has to be shut down and it doesn't reflect to the Application menu properly most of the time (even when I log out it seems). So having a standard or at least a guideline would be helpful.

Advanced Architecture

• Special
  templates
  
• Secured

• 
  Black
  vault (only out data flows, no in)

• Purple
  papers (docstorage)
  
  Sandbox

• Blue
  docstorage (by inspection - hand copied from other VM's)
• Grey
  work (sanitized)
  banking (sanitized)

• Green
  whonix (sys-whonix)
  sanitized (sanitizer)
  
  

• System I/O (networking, USB, SDCard, etc)

[HW42]

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

cubem...@gmail.com:

> Hello, I've been spending time rearranging my Qubes desktop
> architecture - which VM's I want (personal, business, tor, Whonix,
> etc) and their relationships to each other. After much
> experimentation it's clear that while the actual setup will be
> specific to the individual, I think there is a common architecture
> that can be found across most use cases. At least it would be
> useful if had a standard for which types of VM's had which colors.
> With that I'd like to propose a schema for comment, and then put
> my money where my mouth is and offer to implement it

Sorry, but I'm rather skeptical. See below for the more general comment.

But first a few things about your assumptions.

> Assumptions - *Different VM's of the same color should have
> equivalent security*

>
> Without this requirement using colors in the first place is
> useless! Users need to be conditioned to recognize that Green means
> "mostly safe" while Red means "mostly unsafe", for example

That is something which is in my experience only very roughly true. So
yeah I would not use red for a vault VM. But just because two VMs have
the same color does not mean that the security assumptions about the
two are the same. For example I have a green VM with a chat client I'm
playing with and my firewall VM is green like in the default setup.
But the security assumptions are very different. In the chat VM I'm
running code which is only secured by "GitHub SSL" because the client
I'm playing with has no real source code signatures. OTOH this VM gets
the medium level color green because it can contain private chats. The
firewall VM on the other hand handles a lot of different traffic, but
I would rather not run code from foreign sources.

> - *Data flows needs to be bi-directional - and that's OK!*

>
> Truly one directional 'vaults' are useless. Even 'closed wall' top
> security installations have two way information flow - people (with
> sufficient clearance) go in and out. This shows that data can flow

> both directions, as long as it's *controlled*. Likewise, we can

> imagine an ultra-secure "secure-keys" black vault, unconnected to

> any networking with data flow *out* in the form of keys or
> encrypted data.

Given that this is exactly what kills your compartmentalization when
you made a small error this is IMHO a way to vague formulation.

> - *Data flow should be inherent by the design*

>
> More secure VM's should only have data pipes from less secure VM's

Could you please clarify what you mean?

> - *The architecture should mirror the color priority*

>
> That means that Red is insecure and black is totally secure (as
> secure as we can make it!)
>

> - *There are two main use cases, average and advanced user*

>
> KISS
>
>
> With that out of the way let me propose a possible solution.
> Consider a structure such as this, for the advanced user
>
>
>

> - *Advanced Architecture DMZ* (networking, USB, SDCard, etc) - Red
> - Orange - Yellow *Sandbox* - Green - Grey - Blue *Secured* -
> Purple - Black - Special

>
> The "Special" category (no color) includes dom0 and the templates
> (fedora-21). Assuming this, we can simplify it but keep the same
> structure for the average user
>
>

> - *Advanced Architecture System I/O* (networking, USB, SDCard,
> etc) - Red *Sandbox* - Green *Secured* - Black - Special

>
> Now what VM's would go where, given our assumptions. By example we
> can imagine the following setup, the item in parenthesis is the vm

> that *feeds* this one with data through some Qubes mechanism
>
>
> - *Advanced Architecture System I/O* (networking, USB, SDCard,
> etc) - Red *sys-net* (eth0) *usbvm (USB)*
>
> *pentest-wifi playpen* - Orange *sys-firewall* *(sys-net) **snort

> (sys-net) (snort traffic analyzer - used offline for

> attack/intrusion analysis)* - Yellow
>
> *sys-whonix (sys-firewall) social-networking (sys-firewall)*
> *sanitizer* (sys-firewall)* a filter proxy for cleaning PDF's, JPG
> exif, etc
>
> *Sandbox* - Green
>
> *whonix (sys-whonix) sanitized (sanitizer)* - Grey
>
> *work (sanitized) banking (sanitized)* - Blue * docstorage* *(by
> inspection - hand copied from other VM's)*
>
> *Secured* - Purple *papers* (*docstorage*) - Black
>
> *vault (only out data flows, no in) * - Special ...
>
> * The *sanitizer* is an example of a new type of VM. Johanna wrote

> a blog entry about sanitizing, but thought that it would be too
> difficult to have automatic sanitizers. I wonder though, it doesn't
> seem too much to imagine a tool consisting of a set of scripts to
> sanitize mime types that come in.
>
> The simple use case should be clear, just take the Red, Green and
> Black categories,
>
>

> - Red *sys-net*
>
>
> *usbvm sys-firewall * - Green
>
>
> *banking (sys-firewall) personal (sys-firewall) * - Black *vault*
>
> *Summary*

>
> The idea is to have a design standard following a layered approach.
> While users will always be free to create whatever structure they
> want, most will probably fall into whatever design guidelines the
> project has. This is one logical proposal for such a guideline,
> deriving from the assumptions given above.
>
> Thoughts?

As said I'm rather skeptical. How you compartmentalize is a very
individual decision and I don't really see why we need more than the
default colors of the standard setup.

Just choose a arbitrary example: the TorVM/WhonixGateway. For some
people it can be rather critical that the Tor network provide the
anonymity it can provide. So in this case this would be a rather
critical VM (i.e. "more secure" color). OTOH for the most users a
single leak in the TorVM is not so bad and would give the TorVM a
rather "low" color because tor is a rather prominent target.

And there are a lot of things which are not mapped on the color scheme
at all. For example I have a bunch of different VMs I'm using to
remote administrate stuff of other people. Those VMs have all the same
color, because from my POV they have a comparable "security
properties". But a break of compartmentalization between those would I
consider as rather bad.

So I'm personally really happy with the current status: VM colors are
just hints you can use as you like and we have a very rough consensus
of meaning/order.

What might be a good idea, if you think this stuff is to complex for
new users, is to document more example setups. (But making clear those
are just some examples)

HW42
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWOTy+AAoJEOSsySeKZGgWbxcQAIsKWVuNXbwOJMRnaJrpGkgI
2qh14uyhgIZZlvTDrgzcj/gkmz+sMlZ97hDTiktzl5gB/BAPcULbB/AwO9XqnmKd
UpgMJtGJKGXcBzfHHNH2NV7wjQ4kgLGhT1LfFGzijI3Y3iWwKopf//QG5c3GMwkt
4bPf4Yf3tHrAbCwsIYtP56eyMDLLAf7BkgmttVPCMqtLxp0UEBjQ1MboX4WXKaMP
tINmHYxb6SOOj24hiaSVS/+aDJrPduME2l+Qexrx90eCAXdnhvWyAgYRrNt821ek
KKzSFWhGuv2e1New2Lzy3SIUZvFXMQEjI/1xn98DWPuSVotVOeDa33Z8Ct1pFw89
m4kx/jXhLCnbaPjYzGsX+6hq9dx20BZzscWFdiD7Syh1h1qCoZ02kZZWlmnnFiiX
JGVtDs4JlNJS15SmeiU1RVXrIw/AJz7CdaxZqXBmUPqysT5W0yyljdLSv13z7n5B
QJq+gagW5PL1ouwwk1fDRbrHPwnJKNKgc3DI1F4ww8+NfhS5e32T8RL09gLzA5Sa
fiufBZlxLtOv9eGaRcKjbZm1VmIM/IobSxmgNeIBWjxTL5lbtD0N1goiPpneUn/e
r1cJo12oaln2TdH/IiHO9P1SQdzgpktdzwgSeccQp1AqO8/7rjPmm5jnB+8XKHle
/JkgTWeb76nIrx8D5ZcN
=52XX
-----END PGP SIGNATURE-----

[cubem...@gmail.com]

That is something which is in my experience only very roughly true. So
yeah I would not use red for a vault VM. But just because two VMs have
the same color does not mean that the security assumptions about the
two are the same. For example I have a green VM with a chat client I'm
playing with and my firewall VM is green like in the default setup.
But the security assumptions are very different.

That's a fine arrangement too if it works for you, but then one wonders why use colors at all. Color indicates security, but if the "security assumptions are very different" then logically you should be using different colors.
 

Given that this is exactly what kills your compartmentalization when
you made a small error this is IMHO a way to vague formulation.

Sorry that was not clear.
 

> - *Data flow should be inherent by the design*
>
> More secure VM's should only have data pipes from less secure VM's

Could you please clarify what you mean?

Dependencies go from less secure to more secure. Considering the networking example, hardware networking is at the outermost red layer, proxies are inwards from that (yellow, green), and consumers (AppVM's) are even more inward. I see the model here is something like not just security by compartmentalization, but security also by Proxy - as Johanna discussed chaining proxies is a great use case.
 

How you compartmentalize is a very
individual decision and I don't really see why we need more than the
default colors of the standard setup.

Presently the scheme is haphazard. My point is not to dictate what people should do, but at least standardize on a common design for the templates. You get some combination from a new install. Whonix has some other kind of setup, and the examples are different yet.

The rest of your note indicates that you think I'm trying to tell you what to do which is not the case. Of course everybody can and should use whatever works for them, I hope that was clear from the beginning; I'd at least like to see a standardized scheme (unifying Whonix/Tor/defaults at least) for new users, and people that want something simple, with an example of a clean, rational approach.

[Axon]

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

cubem...@gmail.com:

> Assumptions - *Different VM's of the same color should have
> equivalent security*

>
> Without this requirement using colors in the first place is
> useless!

No. Colors are useful even if they do not indicate *equivalent*
security (which is rarely feasible in practice) for precisely the
reason you give immediately below.

> Users need to be conditioned to recognize that Green means "mostly
> safe" while Red means "mostly unsafe", for example

Even if this were true, it would not justify your claim above (namely
that colors must indicate *equivalent* security). Regardless, colors
in themselves are arbitrary and bear whatever meaning the user wishes
to assign to them.

> - *Data flows needs to be bi-directional - and that's OK!*

>
> Truly one directional 'vaults' are useless.

Patently false. Many uses have been repeatedly iterated on these lists.

> Even 'closed wall' top security installations have two way
> information flow - people (with sufficient clearance) go in and
> out. This shows that data can flow both directions, as long as

> it's *controlled*.

Data are not people.

> Likewise, we can imagine an ultra-secure "secure-keys" black

> vault, unconnected to any networking with data flow *out* in the

> form of keys or encrypted data.

Yes, flowing *out* from "secure-keys" is necessary and good, but this
does not justify your claim that the flow of data needs to be
*bi-direction* and hence also flow *in*.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWOUPUAAoJEJh4Btx1RPV8Ul0P/3UQepLsBCCMaHTsS5fOzkgi
GL5O/8XCGH9CHmnoidWlH4r5y1WiTs3k4N5pgIm0ncrxbigot+aN5v48VAa4X9xP
9jAQLKwXc42m0MMGl0Mv1nuPrLiOFyKHSL0/erGgIPft5LWXcq1C3dF5uYS6yp07
CXz7zE+q7UuxSPzD1GapJqL46Jp20PiMS6D/XqDeWYNwA+CLPF+Q3jHhdcTDH2Aq
R+8ug2lIie3I2tQwZlllIBv9cYzzr7B8mM5XBIg6ECMUmMHzpOZ1aG6SL65Hbixf
QW5x0KA/ehwdrY9EyTc/SIsg4TQO/mlQe1+jhNLCtRY3+hIU7WY0eZlBDHFn2LD3
YcHorsk9ciB3ZS6WererUDIKK0/pfodcpKDajDj5BMeq9hRyxfUzQRMP+63iRj9B
cHX9fA//O5PHFzgRRtXhhjA3wuXLQRdFOQNX7oE1DakogjkzURDfmykVnMvcaOhT
+p4cK6afkeG1XFuu8q4aWzA9QmApcpcvFh8/NBcaRn9ZGI1TvVVT3kKn+vQ6sxlF
o1NEYyD26RBs56s1pFJN+loGTn574ExR3s8iuPkMbc2epoRqQXbyMYD7Le/p8CVW
Osh83rmNaT+X/9Hnz15teX5zZbBufXD3lVZ5XD7+j0retmv76ZqtejX1p7hL8vGu
mg77lnL8P4eSE5uvUKv8
=Hf/M
-----END PGP SIGNATURE-----

[HW42]

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

cubem...@gmail.com:
>
>

>> That is something which is in my experience only very roughly
>> true. So yeah I would not use red for a vault VM. But just
>> because two VMs have the same color does not mean that the
>> security assumptions about the two are the same. For example I
>> have a green VM with a chat client I'm playing with and my
>> firewall VM is green like in the default setup. But the security
>> assumptions are very different.
>
>
> That's a fine arrangement too if it works for you, but then one
> wonders why use colors at all. Color indicates security, but if the
> "security assumptions are very different" then logically you should
> be using different colors.

No. Both VMs fall in the the rough category "medium security" [0], but
for very different reasons. So "Different VM's of the same color
should have equivalent security" does not apply. But a common color
make still sense for me.

>> Given that this is exactly what kills your compartmentalization
>> when you made a small error this is IMHO a way to vague
>> formulation.
>>
>
> Sorry that was not clear.
>
>
>>> - *Data flow should be inherent by the design*
>>>
>>> More secure VM's should only have data pipes from less secure
>>> VM's
>>
>> Could you please clarify what you mean?
>>
>
> Dependencies go from less secure to more secure. Considering the
> networking example, hardware networking is at the outermost red
> layer, proxies are inwards from that (yellow, green), and consumers
> (AppVM's) are even more inward. I see the model here is something
> like not just security by compartmentalization, but security also
> by Proxy - as Johanna discussed chaining proxies is a great use
> case.

Ok. That makes your point clearer to me. In some cases this matches my
use cases/experience. But as one very common counter example I would
like to point out the Tor/Whonix use case. Here the ProxyVM has the
higher security/color level than the application, because the proxy
ensures the torification while the application (for example a Browser)
is often the much bigger attack surface.

>>
>> How you compartmentalize is a very individual decision and I
>> don't really see why we need more than the default colors of the
>> standard setup.
>>
>
> Presently the scheme is haphazard. My point is not to dictate what
> people should do, but at least standardize on a common design for
> the templates. You get some combination from a new install. Whonix
> has some other kind of setup, and the examples are different yet.
>
> The rest of your note indicates that you think I'm trying to tell
> you what to do which is not the case.

It would be helpful if you could make it a bit more clearer what you
imagine when you say "standardization". Because I indeed understood
your proposal partially as you would like to "bake in" this design at
least somehow.

> Of course everybody can and should use whatever works for them, I
> hope that was clear from the beginning; I'd at least like to see a
> standardized scheme (unifying Whonix/Tor/defaults at least) for new
> users, and people that want something simple, with an example of a
> clean, rational approach.

[0]:
Actually my metal model of the colors is a bit more fine grained but
that is not relevant to the point.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWOUPXAAoJEOSsySeKZGgWJvAP/05g0Z4dr+YnEJRkFQ+jCI2S
KlrZGLwzPfMimXHquBMJHYSBuJCZmvN67r4nns+dCN5bnDGqRkfZ281BLyBymtg1
77kkN/h4Mtfr2Odh06/0TNbAFxV+XWRXPU+3ePr1KMwZYGXRdTJ3K/YDPrYTy8tK
qbCXQ04tL8l6QHRv0TcJs6fxmPU0o3W+KAV39iEIMLv13fDKCfAcK5FfaLui5HSZ
X5b/x7scmn56klKJ8J5ByCQBFXLWgT/bQyUjjMKB9ssxb94r9lVEgfEVmbtEJ1XJ
CKmtepU1SrQ7+zr4TE1BBY6PF1UN80EfALwA5h7JycBYOcYQJonMgDrUhgx0HJ2u
T9ohvVRAoMz0RpYujSqClc8Ozpv7CUzq916d//i4bcU/6UDOlEZ2YDdsBuQ+63ik
qzoLKQ6redzRQovsTyKpYkKGujBZLyAYM+rm8+yX5OAkMjEnXdGr2H0TdXIc2w4l
MgnZC7K/xgU4uyMgE/VVPHIDPduvz88rkneqQqovVV1Jhk8o3O2fWUkqks5kue4d
znG4xKzkW1Ja2mij9zor3tXhUDC1KsBSBgHyYBqtWbpHV+iPkJVgfEd2bMkIQ1jy
AVBperebPaoWEHFh/J6AhukCkZJR9e4IhzykmHYg5mgRQXeZTIZefc1DwRy7oYaL
OKw6F85EDFEpCUOj5HGa
=/4Q+
-----END PGP SIGNATURE-----

[cubem...@gmail.com]

No. Both VMs fall in the the rough category "medium security" [0], but
for very different reasons. So "Different VM's of the same color
should have equivalent security" does not apply. But a common color
make still sense for me.

Right I got that, so you're using 'color' to mean something other than security, but which is meaningful to you. Again is fine, but I think non-standard? I believe Johanna meant color to indicate security from what I've been reading.

Ok. That makes your point clearer to me. In some cases this matches my
use cases/experience. But as one very common counter example I would
like to point out the Tor/Whonix use case. Here the ProxyVM has the
higher security/color level than the application, because the proxy
ensures the torification while the application (for example a Browser)
is often the much bigger attack surface.

True, but the colors are just a visual indicator for the user, not an indication of attack surface. In this example the user cannot use a ProxyVM directly, s/he has to use an application (in a different VM) which is fed by the ProxyVM. At any rate the user could use a different application than Tor - say lynx, which has a smaller attack surface. I'd argue that from the user standpoint they could either be considered equivalent (most people would), or if somebody is really a security freak they could put lynx (fed by tor-proxy) at a higher level than TOR browser, if they wish.
 

It would be helpful if you could make it a bit more clearer what you
imagine when you say "standardization". Because I indeed understood
your proposal partially as you would like to "bake in" this design at
least somehow.

Well I'm actually making two proposals. One is that we have a common design guideline - I propose one at least as a starting point. This design implies a layered or onion architecture, which seems already to be inherent in the Qubes - just not 'manifest' as it were. Johanna has a blog post describing her set up which is like a graph, but it seems to me that given the architecture of Qubes already has hierarchy (hardwareVM->netVM>ProxyVM->AppVM) that this is perhaps a more natural approach, or maybe more universal. Most people deal with lists (or layers) better than graphs.

[HW42]

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

cubem...@gmail.com:
>
>

>> No. Both VMs fall in the the rough category "medium security"
>> [0], but for very different reasons. So "Different VM's of the
>> same color should have equivalent security" does not apply. But a
>> common color make still sense for me.
>>
>>
> Right I got that, so you're using 'color' to mean something other
> than security, but which is meaningful to you. Again is fine, but I
> think non-standard? I believe Johanna meant color to indicate
> security from what I've been reading.

It's something what I would maybe describe as "rough security level".
Because the details can't be mapped (IMHO) to a simple one dimensional
scale.

Why not different colors?: Because you can only easily
recognize/remember a small number of colors. For the details there is
the VM name, which is much more meaningful (but less easily recognized).

> Ok. That makes your point clearer to me. In some cases this matches
> my
>> use cases/experience. But as one very common counter example I
>> would like to point out the Tor/Whonix use case. Here the ProxyVM
>> has the higher security/color level than the application, because
>> the proxy ensures the torification while the application (for
>> example a Browser) is often the much bigger attack surface.
>>
>
> True, but the colors are just a visual indicator for the user, not
> an indication of attack surface.

Well - in my POV: bigger attack surface -> less secure -> "lower"
color. (so the red for the "random" browser to remind you that it is a
rather easy target so you should remember that it is not so safe)

> In this example the user cannot use a ProxyVM directly, s/he has to
> use an application (in a different VM) which is fed by the ProxyVM.
> At any rate the user could use a different application than Tor -
> say lynx, which has a smaller attack surface. I'd argue that from
> the user standpoint they could either be considered equivalent
> (most people would), or if somebody is really a security freak they
> could put lynx (fed by tor-proxy) at a higher level than TOR
> browser, if they wish.

That how I would do it. (But attack surface is obviously only one
factor for the assessment)

>> It would be helpful if you could make it a bit more clearer what
>> you imagine when you say "standardization". Because I indeed
>> understood your proposal partially as you would like to "bake in"
>> this design at least somehow.
>>
>>
> Well I'm actually making two proposals. One is that we have a
> common design guideline - I propose one at least as a starting
> point. This design implies a layered or onion architecture, which
> seems already to be inherent in the Qubes - just not 'manifest' as
> it were. Johanna has a blog post describing her set up which is
> like a graph, but it seems to me that given the architecture of
> Qubes already has hierarchy (hardwareVM->netVM>ProxyVM->AppVM) that
> this is perhaps a more natural approach, or maybe more universal.
> Most people deal with lists (or layers) better than graphs.

Ok. So you want to improve "only" the documentation? Or you imagine a
change of the software - if so, what changes are you proposing?
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWOUyFAAoJEOSsySeKZGgWvwQP/2ip8c7sFuAINKF+YX7cvhgE
nwFZ3ZOHPGlDGJ3bAQKlgKDmD4nfDpCipdULu4FNvbtESj1U/KdHSXMDdj91p2n6
kuGGrjVksWjkfbuXMphAKVNM4F0OMS3P8rY8YhxKhun6i+e4fxUjubTk+FSXkk9V
/HIbUTIAlQCuf8CwieG4LXJDr4oWCiw+h4DBNuPShw7hZJkjsQf35Su6EV9zno7x
YXPqcBYL37xJmF6Rl/svL+Z4+cssjK6UyRi8LGFOT/c629RyB8lUaG++WR/KoJ7l
/0WQrKhsqDbhR4/x8MxqIZ5fqv2St5Fc9YrubdJe79mlGp166QsFHDvjgTxarHFk
l4SDFLMnuODRziRRFuxQ0seQfSFojZOmi8jeLM3wKsSEPYkMf/LhTFSFVjDCFCh3
TNzy4eNnonfFVj1oN2CBRxglnDnVUPBEA/WMg0MwJcd5s9TbNGFUd4uz3oNg3PEF
zpU+WRs49FEVdelhCErR/fw1mZGufOjCr6cOKeAct5l3As+xPB080obtEswTKZbf
GQNsw0ot0ZGoc4RpV4r2wwRmXwJ/a0SAz5VL26GeHssPvPZw2ZS5vMB5oDYbetro
rZWGCDX/PoJNfSSRuGYanCnR2yaDhkrD1XWJIM+PJeOD6ckp+nZNUkf+QHX4rA74
/VgOrvF2P17X0+xRddL4
=m4DD
-----END PGP SIGNATURE-----

[Franz]

For what I understand cubemammal proposes various standard configurations of VM architecture.

Qubes mailing lists are made mostly of computer professionals who are mostly able to use the huge freedom that Qubes provides. But security is obviously a general need. Also a need of most people who use a computer as an appliance, that means zero freedom, but something easy that works out of the box.

Also a wider Qubes use (outside of computer professionals area) would mean more sustainability for the Qubes project and for Qubes core developers.

So why not giving full consideration to cubemammal effort to preserve full freedom for computer professionals, but limit freedom for normal users that do not understand (and
probably never will) the huge range of different possibilities that Qubes offers.

A normal user is simply lost with so much freedom and so many challenges. For some reason the computer market is shared between Microsoft and Apple that produce appliances, with zero freedom, because they are standardized. But at the same time this market user has low chances to go seriously wrong, even if with weak security.

In other words we should do an effort to look beyond our own needs for the sake of Qubes future.  And rather look at the need of people that tend to understand only appliances, that is something with a quick start manual that tells that a Vault VM is for manually editing credentials, has a certain standard colour and you'll be unable to use it to connect to internet because so tells security.

At the same time this standardization may allow to arrange as much configuration as possible,  such as something of what cubemammal proposes. To prevent the most obvious errors/risks.

Zrubi already told us that nothing will prevent those who do not understand from making security errors. That is true, ma the same something is better than nothing and I am sure that even the very normal user can move towards Qubes and have something more secure if Qubes moves a little bit towards him/her.

Best

Fran  

  

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWOUyFAAoJEOSsySeKZGgWvwQP/2ip8c7sFuAINKF+YX7cvhgE
nwFZ3ZOHPGlDGJ3bAQKlgKDmD4nfDpCipdULu4FNvbtESj1U/KdHSXMDdj91p2n6
kuGGrjVksWjkfbuXMphAKVNM4F0OMS3P8rY8YhxKhun6i+e4fxUjubTk+FSXkk9V
/HIbUTIAlQCuf8CwieG4LXJDr4oWCiw+h4DBNuPShw7hZJkjsQf35Su6EV9zno7x
YXPqcBYL37xJmF6Rl/svL+Z4+cssjK6UyRi8LGFOT/c629RyB8lUaG++WR/KoJ7l
/0WQrKhsqDbhR4/x8MxqIZ5fqv2St5Fc9YrubdJe79mlGp166QsFHDvjgTxarHFk
l4SDFLMnuODRziRRFuxQ0seQfSFojZOmi8jeLM3wKsSEPYkMf/LhTFSFVjDCFCh3
TNzy4eNnonfFVj1oN2CBRxglnDnVUPBEA/WMg0MwJcd5s9TbNGFUd4uz3oNg3PEF
zpU+WRs49FEVdelhCErR/fw1mZGufOjCr6cOKeAct5l3As+xPB080obtEswTKZbf
GQNsw0ot0ZGoc4RpV4r2wwRmXwJ/a0SAz5VL26GeHssPvPZw2ZS5vMB5oDYbetro
rZWGCDX/PoJNfSSRuGYanCnR2yaDhkrD1XWJIM+PJeOD6ckp+nZNUkf+QHX4rA74
/VgOrvF2P17X0+xRddL4
=m4DD
-----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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/56394C86.4070101%40ipsumj.de.

For more options, visit https://groups.google.com/d/optout.

[HW42]

If this is the proposal I'm having no problem with it. But at least to
me it was not so clear based on the email (thats the reason why I
asked to clarify what exactly is being proposed). Maybe I have
associated "standardization" to much with "supported/intended use
case". And the assumption of "Different VM's of the same color should
have equivalent security" and "Data flow should be inherent by the
design" lead me to thinking they may proposing to associate the color
with a security relevant meaning on the technical level (like for
example allowing some rpc calls).

@cubemammal: If my response appeared to be to rejective I'm sorry. I
was considering the general use case. If you want some out of the box
configuration for less advanced use cases: go for it! (It may be
useful to look at the plans to integrate some configuration management
system for automatic setup of common configs/setups). (And I'm
obviously speaking for my self. Not for the Qubes community, and even
less for the ITL. So if I don't like an idea this might be a minority
opinion)

> A normal user is simply lost with so much freedom and so many
> challenges. For some reason the computer market is shared between
> Microsoft and Apple that produce appliances, with zero freedom,
> because they are standardized. But at the same time this market
> user has low chances to go seriously wrong, even if with weak
> security.
>
> In other words we should do an effort to look beyond our own needs
> for the sake of Qubes future. And rather look at the need of
> people that tend to understand only appliances, that is something
> with a quick start manual that tells that a Vault VM is for
> manually editing credentials, has a certain standard colour and
> you'll be unable to use it to connect to internet because so tells
> security.
>
> At the same time this standardization may allow to arrange as much
> configuration as possible, such as something of what cubemammal
> proposes. To prevent the most obvious errors/risks.
>
> Zrubi already told us that nothing will prevent those who do not
> understand from making security errors. That is true, ma the same
> something is better than nothing and I am sure that even the very
> normal user can move towards Qubes and have something more secure
> if Qubes moves a little bit towards him/her.

If you are going to realize that it might be good to define a clear
thread model/scope you want to cover. I think the way Tails handles
this is very good.

> Best Fran

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWOXA2AAoJEOSsySeKZGgWkv4QAINwgIvB4F2508IGnAyNIZYo
QVLlt+DIP4SJNO7YHqNAECq6lPq4Wnao1BLWtTZtoSluFsRGwROHRr8b3M/M44jr
lwZraUqRP+/DbMTeTIZAmAYO/Zd0XPL+PyFn7GwCimx5uYfLpbRcwEoKz/VIU1yY
OGathBb947LKl7/DPYoFbhFR5p6n9PUIKhv4SGsINC+mkouttsUF4pE2oh1uSzcy
O4DhIVd0zGfkN9gtVmxOinTjhe/m7qqMOTSluNCkT4EVcZVP3Hqm1epk0BIPkp3d
JgjqvCEUJCIzsH6vJSMpEvdcK0LC8teY9RGqmqq5KExcw2jfNjLMI1PMgf+S8lHB
weyyc4vbpPmn/eT05GqX+t+FPBbldb8vnDf4a8Wk19L5OfzK2tp6OibTHKxXkeQ0
zdumKxpKeNQb7CccaknQKxIbZSrFKHhnafD6iToy7wOOcHtQBwpTNRAVAWWVvMZe
cuAzUhcH65p1Aa+6MPICYJ/prdWagJ4aIuzlHdN6xP5JkccKUt8w0M0ARKoL68Qk
MSPpwKq1P1WP6Q5gDtXDKpHS626r+6YInN8PpnPC0Ll4/UWy225CWpgDP3O8FeiH
42PIIiMHyMeuA19BrNGMgzLu1WfAUvLUdviw2ksxv8pwR8Jf7jHRJcrdor+IJ79v
P+wDvRMOrc3WhSCT7n9N
=IqEt
-----END PGP SIGNATURE-----

[Laszlo Zrubecz]

On 11/03/2015 10:09 PM, cubem...@gmail.com wrote:
> Hello, I've been spending time rearranging my Qubes desktop
> architecture - which VM's I want (personal, business, tor, Whonix,
> etc) and their relationships to each other. After much
> experimentation it's clear that while the actual setup will be
> specific to the individual, I think there is a common architecture
> that can be found across most use cases. At least it would be
> useful if had a standard for which types of VM's had which colors.
> With that I'd like to propose a schema for comment, and then put my
> money where my mouth is and offer to implement it
>

> Assumptions - /Different VM's of the same color should have
> equivalent security/

>
> Without this requirement using colors in the first place is

> useless! Users need to be conditioned to recognize that Green means

> "mostly safe" while Red means "mostly unsafe", for example

Wrong.

The colors are (also) for you (the user) to be able to distinguish the
application windows from each other.

For example if a password prompt appears with green border - and you
have 4 green VM open...
(yes, the VM name is the real unique id, but for the first look you
will note the color only for sure)

Currently we can't use enough colors to make all VM unique - but there
should be a ticket about this for a long time.


For example my disposable vm's are all red - if I start it 'manually'.

- if its a non networked one (my default) then it is the mopst secure.
- if it is network connected, and I using it for malware testing -
this will be the less secure one.

But if you start it from another AppVM (currently) it will inherit the
color of the originating VM. However you will decide what content are
you put/get in that VM.

So the color vs security assumptions will fail.


> - /The architecture should mirror the color priority/

>
> That means that Red is insecure and black is totally secure (as
> secure as we can make it!)

Depends on the first assumption.


> - /There are two main use cases, average and advanced user/
>
> KISS

The average qubes user is an advanced user in any other system for sure
;)


> ... *Summary*
>
> * *The idea is to have a design standard following a layered

> approach. While users will always be free to create whatever
> structure they want, most will probably fall into whatever design
> guidelines the project has. This is one logical proposal for such a
> guideline, deriving from the assumptions given above.
>
>
> Thoughts?

Well

- As I see the internal vm network design can be common - the colors
are not.

- All domU VMs are on the SAME seucrity level by default.
This means only the user can (and should) decide what will be the
purose of a given VM. And the purpose will predict the security level
of that VM.

The only exeptions are the sys-net, and sys-firewall VM types - but
these are the vital part of the netwrok design.


- sys-net will be always at risk - because of the direct connection of
the external network.

- sys-firewall can wary - depending on the use case
- outgoing packet filtering (Qubes firewall)
- handling VPN connections
- TOR
- Whonix
- any other proxy/IDS/IPS like usage.

- AppVMs are really depends only the user. There are no real common
use cases.


Some really good writing about these topics from Joanna:

http://theinvisiblethings.blogspot.hu/2011/03/partitioning-my-digital-li
fe-into.html

http://theinvisiblethings.blogspot.hu/2011/09/playing-with-qubes-network
ing-for-fun.html


My two cents.


--
Zrubi

--
You received this message because you are subscribed to the Google

Groups "qubes-users" group.

To unsubscribe from this group and stop receiving emails from it, send

an email to qubes-users...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit

https://groups.google.com/d/msgid/qubes-users/5639BEBF.2000301%40zrubi.hu.

[Zrubi]

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

Sorry for the cross-post

I just messed it up.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWOb9nAAoJEC3TtYFBiXSvK2cP/2VFErb6XqY3imnp8QqszmQL
oXx9yI2yjMjX/LRodceNgq0zzfi79epbHh7a2kozYMUTy9PEy2Cx8mrSDhbRDTBj
6e0LHg9uWzgzjvp3ZFFbWRJzxRenFRRXKmj5E7yE6CrKp9+DlZIYS/0tDGRZNdMQ
rHO1t21WesbVXttqIC3qq4i6byD0a2XMcWYz3IzpDu6XNYnTngWfwIJnk/67kwP5
Fz+xDdJRbfLGxDFtZxCMwPYU/DTESpy6Oy7n7iy6vLNZSuQXDoJGFYZjbz5uc0bY
WKsYp/mUDBFi3+hSZsrMI2q4KW7JdUkSFGk+Hz3JkV+X7WyaDle+FqD+kOMeAcW5
bywv99MxCU42ze7ugqNMQWPpfHjFy/2iUGrRFX0mmAOp8n9zDuIKiZ1wkrAigkxN
GnbJcHHRrZ0XjIaPxt2p+4geKGyytNA8as1PeRwl/jJ5O981Tth7o8S759hz7iux
FS+tgEdsG2yx8nl3md+ihrItOwGMhClM1u5IhLaJaL1uC9XL7eKfJCFxp0ECW69X
A6LNzQpsmK65G9/iLZrKGHkhdmDLeoQNVa6d5GehzRNDKFoZujqgmsAyCjFwnO8C
e/9NgasLAXUQafKjEXmCIZs1BWZMD4tIxtCcZFTl0Cr/9NTOmkD6ledNj6Ftbn1Y
4EwokYtgrUhFKV9oDdGD
=d0/2
-----END PGP SIGNATURE-----

[cubem...@gmail.com]

For what I understand cubemammal proposes various standard configurations of VM architecture.

Correct, sorry that wasn't clear. I tried to make it obvious but text communication isn't always so easy.

 

Qubes mailing lists are made mostly of computer professionals who are mostly able to use the huge freedom that Qubes provides. But security is obviously a general need. Also a need of most people who use a computer as an appliance, that means zero freedom, but something easy that works out of the box.

Also a wider Qubes use (outside of computer professionals area) would mean more sustainability for the Qubes project and for Qubes core developers.

So why not giving full consideration to cubemammal effort to preserve full freedom for computer professionals, but limit freedom for normal users that do not understand (and
probably never will) the huge range of different possibilities that Qubes offers.

My proposal is less restrictive than this; I'm not suggesting we limit freedom at all, but just have it come out of the box with a simple, standard configuration with color consistency? Just like Microsoft Windows. Nothing stops anybody from changing the Start menu to be whatever they want, advanced user or not, but at least it always starts with a setup that makes sense to most people.
 

Zrubi already told us that nothing will prevent those who do not understand from making security errors. That is true, ma the same something is better than nothing and I am sure that even the very normal user can move towards Qubes and have something more secure if Qubes moves a little bit towards him/her.

Correct, the platform is maturing enough (and especially with upcoming UEFI support) will probably attract a wider audience, many of whom would throw up at the initial complexity of setting it up.

I've got decades of experience as an engineer and computer security, but even for me coming up to speed on Qubes was really challanging. Which is fun, I did it in a week or so, but if it was that difficult for me then it makes me think it really is much too difficult for the other 99%, out of the box. 

[Franz]

Yes of course, but to understand that one should be able to look from the point of view of another very different person. But most people are simply unable to do that. That is why those who can are so greatly successful in life. Steve Jobs is of course an example of being able to let ordinary people access and use complex technology. But even in our beloved open source sector this is a generally unanswered crucial need. The more so because one tend to think that because it is free and open we can simply follow what we like. And of course what a programmer likes is very, but very different from what an ordinary man or woman needs.

--
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...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/99d4d031-3ce1-47c1-81b3-a7dd06750c0b%40googlegroups.com.

[cubem...@gmail.com]

Yes of course, but to understand that one should be able to look from the point of view of another very different person. But most people are simply unable to do that.

Actually it's simpler than that; it's just one of investment. Open source development has limited time and interest, so people stick to core functionality and usability gets tossed under the bus. The same is true in corporate development too most of the time. Time is always a limiting factor. All the engineers I work with know how to make usable software, they just rarely get the time.

[timwelter]

I agree.  Your typical end user which makes up 99% of users out there need training wheels to feel comfortable especially if something is a new concept but even in general.  They want standard setups that help them use a system. 

Most of us are actually professional IT users and up  i.e a minimum of one step above a power user.  It does not matter what basic standard lay out Qubes offers as a default for the basic level user it will not have any effect on our usage as we can configure it to whatever we want to make it.  Leave it this way as the default will be over whelming to 99% of those that use PCs these days.   

The easier Qubes is to use/understand out of the box having the least amount of specialize knowledge to get it up and running to a basic level of proficiency the more accepted it will be.  .

Cheers,

Tim

[Manuel Amador (Rudd-O)]

On 11/03/2015 11:01 PM, HW42 wrote:
> Assumptions - *Different VM's of the same color should have
> > equivalent security*

This is very similar to the concept of multi-level security (orange
book, check it out), but Qubes provides no mechanisms to enforce such a
security policy -- you have to roll your own.

--
Rudd-O
http://rudd-o.com/