deeplow commented 4 years ago

Qubes OS version Related to R4.0

Affected component(s) or functionality Documentation: first diagram on the intro page

Brief summary The "intro" diagram (available at https://www.qubes-os.org/intro/) has some issues that need fixing (see "Expected Behavior" section)

To Reproduce View the first diagram at https://www.qubes-os.org/intro/

Expected behavior

sys-whonix connected to sys-firewall
naming: AppVM1, AppVM2, AppVM3
edited later: sys-net color should be red (untrusted)
edited later: Whonix DispVM (AppVM3) has Tor Browser

Actual behavior

sys-whonix connected to networking hardware
naming: AppVM1, AppVM2, AppVM2
edited later: sys-net color is gree (trusted)
edited later: Whonix DispVM (AppVM3) has Firefox

Screenshots

Note: This diagram is outdated. See latest comments for a more recent version

Current	Proposal

Additional context

Issue originally brought up by GWeck on this forum thread
Related pull request for changing the diagrams: https://github.com/fepitre/qubes-diagrams/pull/1

Solutions you've tried

see related pull request: https://github.com/fepitre/qubes-diagrams/pull/1

Relevant documentation you've consulted

Related, non-duplicate issues none

fepitre commented 4 years ago

@andrewdavidwong @marmarek currently the most updated fork it's mine and QubesOS does not have one. Maybe it's time to?

andrewdavidwong commented 4 years ago

Minor thing: Could you drop the solid black border that goes around the entire diagram? IMHO, it would be better to handle the border in CSS around the embedded image, if a border is even needed.

andrewdavidwong commented 4 years ago

currently the most updated fork it's mine and QubesOS does not have one. Maybe it's time to?

I agree that it makes sense to keep the canonical source files in a @QubesOS repo. We have qubes-artwork, but I'm not sure whether it's intended for these sorts of diagrams.

What do you think, @marmarek?

deeplow commented 4 years ago

Minor thing: Could you drop the solid black border that goes around the entire diagram?

Yes! I was thinking I was the only one who disliked that border (so I tried to keep it as close to the original as possible). Then I'll make that change.

Also, can I overload this thread to (attempt to) make some additional contributions on the diagram? @andrewdavidwong

deeplow commented 4 years ago

Black border removed waiting for merging: https://github.com/fepitre/qubes-diagrams/pull/2

I made it so it has a transparent background but all elements are filled with white background (hardware boxes, and the disk). So in case someone wants to share this on their blog or something, where they have a non-white background, it should look decent-enough.

qubes-trust-level-architecture

deeplow commented 4 years ago

Just noticed another problem. AppVM3 should have TorBrowser there instead of firefox (Firefox over Tor undermines Tor's anonymity advantages).

firefox >>>> torbb

andrewdavidwong commented 4 years ago

Also, can I overload this thread to (attempt to) make some additional contributions on the diagram? @andrewdavidwong

That seems appropriately in-scope for this issue.

deeplow commented 4 years ago

Quoting @andrewdavidwong from the forum to keep everything related here:

Yes, sys-net should also be red.

Ok. Then I make that red, but then I also make the networking hardware red as well?

usb_hw >>>> net_hw

Also @andrewdavidwong can I also change the firefox icon to Tor Browser? (as in the above comment)

deeplow commented 4 years ago

Some more questions regarding how this new sys-net untrustedness propagates. Should the connection between sys-net and sys-firewall also be red? (or leave it as green?)

Here's an example:

untrustedness

fepitre commented 4 years ago

Quoting @andrewdavidwong from the forum to keep everything related here:

Yes, sys-net should also be red.

Ok. Then I make that red, but then I also make the networking hardware red as well?

I would say yes because it's the default case in QubesOS. All the network devices go to sys-net.

>>>>

Also @andrewdavidwong can I also change the firefox icon to Tor Browser? (as in the above comment)

I think it makes sense.

Also, don't hesitate to force push or to do multiple new things in your current pull request. Just edit the PR description and add prefix of related changed/new thing in your commit description if it helps.

fepitre commented 4 years ago

currently the most updated fork it's mine and QubesOS does not have one. Maybe it's time to?

I agree that it makes sense to keep the canonical source files in a @QubesOS repo. We have qubes-artwork, but I'm not sure whether it's intended for these sorts of diagrams.

What do you think, @marmarek?

@marmarek will decide of it but, from my humble view of qubes-artwork, it's mostly for in-Qubes components (icons, wallpapers etc). Another possibility could be the qubes-doc repository as a content resource. Maybe not all would be used but it's useful for talks etc.

deeplow commented 4 years ago

Currently looking like this:

qubes-trust-level-architecture

andrewdavidwong commented 4 years ago

Ok. Then I make that red, but then I also make the networking hardware red as well?

Yes.

Also @andrewdavidwong can I also change the firefox icon to Tor Browser? (as in the above comment)

Yes.

Some more questions regarding how this new sys-net untrustedness propagates. Should the connection between sys-net and sys-firewall also be red? (or leave it as green?)

Not sure about that. The edges in this graph are a bit under-defined. In this case, I suppose the inter-VM connection itself is trusted, so I'd be inclined to make it green (or perhaps even half green fading into half red).

andrewdavidwong commented 4 years ago

Oh, I'd also recommend changing sys-whonix to black, since that's the default in Qubes.

deeplow commented 4 years ago

Not sure about that. The edges in this graph are a bit under-defined. In this case, I suppose the inter-VM connection itself is trusted

sys-USB to AppVM 1 is also red, hence my question.

I'd be inclined to make it green (or perhaps even half green fading into half red).

Hum. I'm more compelled to make it green. The fading effect might lead the user to think that there is some sort of filtration effect on the inter-VM connection it self -- which there isn't (AFAIK)

Oh, I'd also recommend changing sys-whonix to black, since that's the default in Qubes.

Will do!

andrewdavidwong commented 4 years ago

Hum. I'm more compelled to make it green. The fading effect might lead the user to think that there is some sort of filtration effect on the inter-VM connection it self -- which there isn't (AFAIK)

Ok, sounds good.

IMHO: At some point, we need to accept that these kinds of abstract representations can never capture all the details about how things actually work. It's good to strive for accuracy at our chosen level of representation, but we should also control the desire to make sure every last facet of reality is depicted, since this can lead to cryptic symbolism that only we understand.

I greatly appreciate your work and initiative on this, @deeplow. :slightly_smiling_face:

deeplow commented 4 years ago

I have implemented the above changes. See https://github.com/fepitre/qubes-diagrams/pull/2#issuecomment-688670041

deeplow commented 4 years ago

Making GUI VM and Template Trusted

Now to keep everything consistent @fepitre @andrewdavidwong I have another proposal

After

qubes-trust-level-architecture_proposal

Before

qubes-trust-level-architecture

Logic behind (propposed) change

Regarding that:

Now that sys-whonix is grey(-ish / black) it in the diagram is more trusted than the templates and GUI VM
In qubes the template VMs are black

I would advocacte for:

Making GUI VM and Templates Gray as:
- better match the default colors in Qubes (Grey != black but we need a color to represent even more trusted components - and grey is close enough; plus no default machine is grey so no need for confusion)
- be more consistent - templates are at least as trusted as vault-VMs / sys-whonix
Replacing blue color with gray:
- with these replacements the color blue in the diagram becomes useless so we replace it with grey
Making AdminVM / XEN as pure black since:
- it represents the ultimate level of trust

How does this sound?

GWeck commented 4 years ago

This would also make it more consistent with the colours in the architecture diagram in Qubes Architecture Overview.

andrewdavidwong commented 4 years ago

better match the default colors in Qubes (Grey != black but we need a color to represent even more trusted components - and grey is close enough; plus no default machine is grey so no need for confusion)

Indeed, this is also a bit of a problem in Qubes OS itself: https://github.com/QubesOS/qubes-issues/issues/3102

[...] How does this sound?

Good ideas. I agree with your proposed changes.

deeplow commented 4 years ago

I've made said changes. Just to final things: @fepitre @andrewdavidwong

andrewdavidwong:

deeplow: Some more questions regarding how this new sys-net untrustedness propagates. Should the connection between sys-net and sys-firewall also be red? (or leave it as green?)

Not sure about that. The edges in this graph are a bit under-defined. In this case, I suppose the inter-VM connection itself is trusted, so I'd be inclined to make it green (or perhaps even half green fading into half red).

Sorry, for insisting on tiny details, but I just noticed that in the qubes-components diagram this sys-net-sys-firewall edge is red. Even though edges are a bit undefined, I think they should at least be consistent. Then we keep the green here and later changed the other. Or we do it the other way around?

qubes-consistency

And the last thing: USB keyboard in the qubes-components diagram is represented (left) while here it is not (right). Shall we include it as well?

keyboard usb

fepitre commented 4 years ago

Sorry, for insisting on tiny details, but I just noticed that in the qubes-components diagram this sys-net-sys-firewall edge is red. Even though edges are a bit undefined, I think they should at least be consistent. Then we keep the green here and later changed the other. Or we do it the other way around?

Don't worry it's great what you are doing. I would go with a green link between sys-net-sys-firewall because when updating templates we are directly "plugged" to sys-net so I would vote for a green connection.

And the last thing: USB keyboard in the qubes-components diagram is represented (left) while here it is not (right). Shall we include it as well?

You can add keyboard indeed. Better keep the same amount of information.

andrewdavidwong commented 4 years ago

Sorry, for insisting on tiny details

No apology necessary!

I would go with a green link between sys-net-sys-firewall because when updating templates we are directly "plugged" to sys-net so I would vote for a green connection.

I'm not quite sure I understand the rationale. I could imagine someone arguing the opposite: sys-net is untrusted, so plugging directly into it is risky, or something. (Not saying I disagree with you or that this hypothetical argument is any good. Just saying I don't understand.)

You can add keyboard indeed. Better keep the same amount of information.

Agreed.

GWeck commented 4 years ago

Some more thoughts on colours:

The proposed scheme lets some colours (orange, blue, purple) without relation to a trust level. This makes sense, since there are lots of possibilities to create VMs that are somewhat trustworthy (perhaps comparable to the "yellow" level of AppVM1 in the diagram), but without a possibilty of declaring them more or less trusted than other ones, e.g.

a VM used for browsing only trusted websites, like banking or so, possibly restricted by firewall rules to access only such selected addresses;
a VM used to process office documents exchanged with selected (business) partners, such that these documents may be regarded as trustworthy (but remember Emotet!);
a template based Windows AppVM restricted by firewall rules to the local network such that any telemetry data transfer is blocked;
a VM used only for mail exchange, restricted to access only a dedicated mail server.

These VMs are more trustworthy than a VM used for arbitrary browsing (like the VM "untrusted" in the default configuration), but less trustworthy than an isolated VM like "vault", but it would be difficult to say if any of them was more ore less trustworthy than another of them.

So it is good to have the possibilty of assigning different colours to them without meaning any ordering of their trustworthiness. The yellow level in the diagram thus stands for a multitude of different security models without any ordering, which is much more than most systems used to access classified information are able to support.

deeplow commented 4 years ago

The proposed scheme lets some colours (orange, blue, purple) without relation to a trust level.

So it is good to have the possibilty of assigning different colours to them without meaning any ordering of their trustworthiness.

I agree with you, but I don't interpret the diagram as telling people explicitly that's how they should do things. The purpose here is to explain to people what are the multiple components and their associated trust level. As andrewdavidwong pointed out earlier, the more complexity we add to the diagram, the harder it is to decipher each part (with other words).

What we seem to be pushing for here, it to have a diagram which is more consistent with the default coloring and icons to the default Qubes configuration.

But I think that strategies to organize the qubes (whether by trust level or something else) could be something addressed in the documentation.

andrewdavidwong commented 4 years ago

But I think that strategies to organize the qubes (whether by trust level or something else) could be something addressed in the documentation.

This may be getting into #2646 territory.

GWeck commented 4 years ago

Completely o.k. The diagram should not be overloaded, but it is a good thing that Qubes provides these possibilities of organizing VMs.

deeplow commented 4 years ago

The only thing missing was just a (re-clarification) on the sys-net sys-firewall interconnect but upon re-reading the conversation, it seems both @andrewdavidwong and @fepitre agree it should be green (as it is now). So I think we can move forward and merge this and address fixes in the components diagram later. Sound good?

But I think that strategies to organize the qubes (whether by trust level or something else) could be something addressed in the documentation.

This may be getting into #2646 territory.

Yes, let's keep the conversations separate.

fepitre commented 4 years ago

I'm not quite sure I understand the rationale. I could imagine someone arguing the opposite: sys-net is untrusted, so plugging directly into it is risky, or something. (Not saying I disagree with you or that this hypothetical argument is any good. Just saying I don't understand.)

@andrewdavidwong Sorry if I was no clear. I was meaning that the update proxy runs into sys-net so when updating template, it uses directly sys-net and not sys-firewall. So I was seeing this connection as green. I don't know the historical choice for using sys-net as holding the update proxy and not sys-firewall.

The only thing missing was just a (re-clarification) on the sys-net sys-firewall interconnect but upon re-reading the conversation, it seems both @andrewdavidwong and @fepitre agree it should be green (as it is now). So I think we can move forward and merge this and address fixes in the components diagram later. Sound good?

@deeplow I'm waiting for Andrew's final feedback but it looks good for me.

fepitre commented 4 years ago

BTW, once the pending PR is done I've asked to @marmarek and we will fork qubes-diagrams into QubesOS. @andrewdavidwong you should then be able to merge this into it too.

andrewdavidwong commented 4 years ago

Looks good to me. Thank you!

fepitre commented 4 years ago

@andrewdavidwong @deeplow I've forked qubes-diagrams into https://github.com/QubesOS/qubes-diagrams with latest PR merged.

andrewdavidwong commented 4 years ago

The new version is now live on the website! :tada:

Thank you @deeplow, @fepitre, and @GWeck!

fepitre commented 4 years ago

I really like it!

QubesOS / qubes-issues

documentation: some issues with intro diagram #6034

Making GUI VM and Template Trusted

After

Before

Logic behind (propposed) change