Security FAQ page?

[rootkovska]

We should probably have a page explaining some less obvious aspects of security architecture and implementation of Qubes OS. The list of topics could be constructed by observing people asking (good or popular) questions on our ML or on Twitter.

One example could be this: how does Qubes assure good randomness in VMs and how does the systemd-random-seed and specifically our qubes-random-seed.sh work? E.g. why using /dev/urandom from Dom0 to seed the VMs is ok.

Perhaps we could have a section/page on https://www.qubes-os.org/doc/, preferably within the "Security Information" section, something like "Security FAQ"?

Perhaps we could also link to our upcoming "List of Xen vulnerabilities which do and do not affect Qubes OS" page? (#2703)

[andrewdavidwong]

Do I understand correctly that some of the information that would appear on this Security FAQ page is currently distributed across the Security Guidelines, User FAQ, and Dev FAQ? If so, there would be two basic parts:

• Move information from those pages to the Security FAQ page.
• Add new information (that isn't anywhere on the site yet) to the Security FAQ page.

If we were to do this, we would end up with three different FAQs (User, Dev, and Security). Perhaps it would be better to consolidate them all into a single FAQ with three sections. What do you think?

[andrewdavidwong]

Do I understand correctly that some of the information that would appear on this Security FAQ page is currently distributed across the Security Guidelines, User FAQ, and Dev FAQ? If so, there would be two basic parts:

• Move information from those pages to the Security FAQ page.
• Add new information (that isn't anywhere on the site yet) to the Security FAQ page.

If we were to do this, we would end up with three different FAQs (User, Dev, and Security). Perhaps it would be better to consolidate them all into a single FAQ with three sections. What do you think?

[jpouellet]

IMHO the qubes docs generally right now has a pattern of pages with similar (but not quite identical) goals which could benefit from some merging and/or restructuring.

For example, there are three similar and partially duplicate pages on copying between domains:

• https://www.qubes-os.org/doc/copy-paste/
• https://www.qubes-os.org/doc/copying-files/
• https://www.qubes-os.org/doc/copy-from-dom0/

I remember cases on the mailing lists where it seemed people had read one but not noticed the existence of another.

I started to deduplicate them, but... other priorities.

[jpouellet]

IMHO the qubes docs generally right now has a pattern of pages with similar (but not quite identical) goals which could benefit from some merging and/or restructuring.

For example, there are three similar and partially duplicate pages on copying between domains:

• https://www.qubes-os.org/doc/copy-paste/
• https://www.qubes-os.org/doc/copying-files/
• https://www.qubes-os.org/doc/copy-from-dom0/

I remember cases on the mailing lists where it seemed people had read one but not noticed the existence of another.

I started to deduplicate them, but... other priorities.

[andrewdavidwong]

Reassigning to @rootkovska to answer the questions posed above.

In addition, since it's been eight months since our last activity on this issue, I want to make sure the original goals of this issue are still the same.

[andrewdavidwong]

Reassigning to @rootkovska to answer the questions posed above.

In addition, since it's been eight months since our last activity on this issue, I want to make sure the original goals of this issue are still the same.

[rootkovska]

Consolidations into single pages (but with a good structure that allows to easily bookmark into specific subsection) is always good, IMHO.

[rootkovska]

Consolidations into single pages (but with a good structure that allows to easily bookmark into specific subsection) is always good, IMHO.

[andrewdavidwong]

One example could be this: how does Qubes assure good randomness in VMs and how does the systemd-random-seed and specifically our qubes-random-seed.sh work? E.g. why using /dev/urandom from Dom0 to seed the VMs is ok.

@rootkovska or @marmarek, could you please provide (or point me to) the answers to these questions? I want to make sure I include accurate answers in the FAQ.

[andrewdavidwong]

One example could be this: how does Qubes assure good randomness in VMs and how does the systemd-random-seed and specifically our qubes-random-seed.sh work? E.g. why using /dev/urandom from Dom0 to seed the VMs is ok.

@rootkovska or @marmarek, could you please provide (or point me to) the answers to these questions? I want to make sure I include accurate answers in the FAQ.

[andrewdavidwong]

One example could be this: how does Qubes assure good randomness in VMs and how does the systemd-random-seed and specifically our qubes-random-seed.sh work? E.g. why using /dev/urandom from Dom0 to seed the VMs is ok.

@rootkovska or @marmarek, could you please provide (or point me to) the answers to these questions? I want to make sure I include accurate answers in the FAQ.

Bump.

[andrewdavidwong]

One example could be this: how does Qubes assure good randomness in VMs and how does the systemd-random-seed and specifically our qubes-random-seed.sh work? E.g. why using /dev/urandom from Dom0 to seed the VMs is ok.

@rootkovska or @marmarek, could you please provide (or point me to) the answers to these questions? I want to make sure I include accurate answers in the FAQ.

Bump.

[rustybird]

The last question could be answered "using /dev/urandom from Dom0 to seed the VMs is ok because initialized /dev/urandom is ok for everything", and systemd-random-seed.service takes care of initialization in dom0 before any VMs are started. When python3 >= 3.6 lands in dom0, there'll be a failsafe on top of that: blocking-mode os.urandom().

[rustybird]

The last question could be answered "using /dev/urandom from Dom0 to seed the VMs is ok because initialized /dev/urandom is ok for everything", and systemd-random-seed.service takes care of initialization in dom0 before any VMs are started. When python3 >= 3.6 lands in dom0, there'll be a failsafe on top of that: blocking-mode os.urandom().

[adrelanos]

Entropy is required before systemd, let alone systemd-random-seed.service is available. The kernel requires entropy.

The following website gives a few details:
https://www.av8n.com/computer/htm/secure-random.htm

mirage invented xentropyd
https://github.com/mirage/xentropyd

KVM invented Virtio RNG
https://fedoraproject.org/wiki/Features/Virtio_RNG

Xen has no such equivalent.

One could argue, that the entropy used before systemd-random-seed.service is "not so important", but I am not aware of any research done in that area. I am afraid, this could be one of the biggest blind spots of Qubes.

[adrelanos]

Entropy is required before systemd, let alone systemd-random-seed.service is available. The kernel requires entropy.

The following website gives a few details:
https://www.av8n.com/computer/htm/secure-random.htm

mirage invented xentropyd
https://github.com/mirage/xentropyd

KVM invented Virtio RNG
https://fedoraproject.org/wiki/Features/Virtio_RNG

Xen has no such equivalent.

One could argue, that the entropy used before systemd-random-seed.service is "not so important", but I am not aware of any research done in that area. I am afraid, this could be one of the biggest blind spots of Qubes.

[rustybird]

Entropy is required before systemd, let alone systemd-random-seed.service is available. The kernel requires entropy.

Can you point me to some information on that? The first link mentions generating keys and setting up network connections, but it seems that either of those should happen way after systemd-random-seed.service inside a VM.

I just checked one thing that seemed "promising", MAC randomization - but NetworkManager has DefaultDependencies=yes, so it is ordered after basic.target <- sysinit.target <- systemd-random-seed.service.

It would definitely be interesting, from a holistic perspective, to trace if any random data is consumed from a nonblocking source before random initialization on a modern system, whether it is running inside a VM or on bare metal...

Xen has no such equivalent.

Isn't the Qubes drop-in for systemd-random-seed.service the equivalent? It's not a daemon that continuously feeds entropy, but that could be harmful anyway, sez djb:

Let me emphasize that what I'm advocating here, for security reasons, is a sharp transition between

• before crypto: the whole system collecting enough entropy;
• after: the system using purely deterministic cryptography, never adding any more entropy.

[rustybird]

Entropy is required before systemd, let alone systemd-random-seed.service is available. The kernel requires entropy.

Can you point me to some information on that? The first link mentions generating keys and setting up network connections, but it seems that either of those should happen way after systemd-random-seed.service inside a VM.

I just checked one thing that seemed "promising", MAC randomization - but NetworkManager has DefaultDependencies=yes, so it is ordered after basic.target <- sysinit.target <- systemd-random-seed.service.

It would definitely be interesting, from a holistic perspective, to trace if any random data is consumed from a nonblocking source before random initialization on a modern system, whether it is running inside a VM or on bare metal...

Xen has no such equivalent.

Isn't the Qubes drop-in for systemd-random-seed.service the equivalent? It's not a daemon that continuously feeds entropy, but that could be harmful anyway, sez djb:

Let me emphasize that what I'm advocating here, for security reasons, is a sharp transition between

• before crypto: the whole system collecting enough entropy;
• after: the system using purely deterministic cryptography, never adding any more entropy.

[rustybird]

It would definitely be interesting, from a holistic perspective, to trace if any random data is consumed from a nonblocking source before random initialization on a modern system, whether it is running inside a VM or on bare metal...

Huh, looks like the kernel would already print random: prefixed notice messages about "uninitialized" (crng_init == 0) random use, both by kernel space consumers (message emitted by _warn_unseeded_randomness()) and by userspace consumers (message emitted by urandom_read()).

At the next level, "initialized" (crng_init == 1, "random: fast init done" message), it has collected enough entropy from the environment to not block/warn anymore - but it's probably low quality entropy in a VM?

And at the last level, "initialized from input_pool" (crng_init == 2, "random: crng init done" message), it has been reseeded (= seeded from userspace). If I'm getting this right.

So apparently, adding a warning on (crng_init < 2) at the top of _warn_unseeded_randomness() and urandom_read() could settle the question. Is someone in the mood to recompile their VM kernel? Cause I'm not.

[rustybird]

It would definitely be interesting, from a holistic perspective, to trace if any random data is consumed from a nonblocking source before random initialization on a modern system, whether it is running inside a VM or on bare metal...

Huh, looks like the kernel would already print random: prefixed notice messages about "uninitialized" (crng_init == 0) random use, both by kernel space consumers (message emitted by _warn_unseeded_randomness()) and by userspace consumers (message emitted by urandom_read()).

At the next level, "initialized" (crng_init == 1, "random: fast init done" message), it has collected enough entropy from the environment to not block/warn anymore - but it's probably low quality entropy in a VM?

And at the last level, "initialized from input_pool" (crng_init == 2, "random: crng init done" message), it has been reseeded (= seeded from userspace). If I'm getting this right.

So apparently, adding a warning on (crng_init < 2) at the top of _warn_unseeded_randomness() and urandom_read() could settle the question. Is someone in the mood to recompile their VM kernel? Cause I'm not.

[andrewdavidwong]

The entropy issue is clearly a point of contention that requires further testing and lies beyond my expertise. I've created the Security FAQ section and populated it with all desired FAQs except that one. Therefore, I'm closing this issue as complete and leaving the entropy issue to #673.

[andrewdavidwong]

The entropy issue is clearly a point of contention that requires further testing and lies beyond my expertise. I've created the Security FAQ section and populated it with all desired FAQs except that one. Therefore, I'm closing this issue as complete and leaving the entropy issue to #673.