persist random seed files [entropy] in TemplateBasedVMs

[adrelanos]

There are various issues wrt to the security of randomness / entropy in Linux distributions generally. (therefore also in Qubes). More so in VMs and read-only media. I am unable to express most of them for now. Please read the following:
https://www.av8n.com/computer/htm/secure-random.htm

However, one argument is easy to make. For Debian, the following files are supposed to persist as per Debian defaults.

• /var/lib/urandom/random-seed
• /var/lib/systemd/random-seed
• /var/lib/random-seed

As long as Qubes does not solve all the entropy issues in a more clever way, The-Right-Thing-To-Do (tm) is to do as per upstream (Debian) provisions. To persist those.

This requires the bind-dirs functionality (https://github.com/marmarek/qubes-core-agent-linux/pull/58). Once this got merged, solving this very ticket requires no more than a drop-in config file for bind-dirs.

Standalone and TemplateVMs should already persist these random seed files, right?

Dunno about DispVMs. I fear those are another issue that is as complicated as solving the entropy issues for read-only media.

[v6ak]

First, this should be handled by #1311 . This AFAIK solves the issue for all the PVs, including DVMs. But template-based HVMs are a special care we probably can't do much about, except adding some warning.

Note that just moving random seed to /rw would not solve the problem fully, because /rw gets cloned when a new VM is created, so some information about template would be maybe leaked in such case. To make things worse, any VM can start a fresh DVM and try to examine its RNG. Alternatively, when the filesystem relocates the random seed after boot, the attacker might even find the original random seed.

But I don't consider these concerns to be so important, since PVs are seeded from dom0 and dom0 does not have this issue.

[v6ak]

First, this should be handled by #1311 . This AFAIK solves the issue for all the PVs, including DVMs. But template-based HVMs are a special care we probably can't do much about, except adding some warning.

Note that just moving random seed to /rw would not solve the problem fully, because /rw gets cloned when a new VM is created, so some information about template would be maybe leaked in such case. To make things worse, any VM can start a fresh DVM and try to examine its RNG. Alternatively, when the filesystem relocates the random seed after boot, the attacker might even find the original random seed.

But I don't consider these concerns to be so important, since PVs are seeded from dom0 and dom0 does not have this issue.

[cfcs]

Alternatively the VMs could regularly feed entropy back to dom0, and dom0 could be configured to supply all new PVs with "new" seed files from its /dev/urandom. I believe this would result in overall added entropy?

[cfcs]

Alternatively the VMs could regularly feed entropy back to dom0, and dom0 could be configured to supply all new PVs with "new" seed files from its /dev/urandom. I believe this would result in overall added entropy?

[v6ak]

Transferring entropy from DomUs to dom0 looks crazy. Theoretically, there is nothing wrong with this (unless entropy estimate is increased by this operation), but I feel this to be strange. Moreover, there are some design considerations, like how frequently this should occur.

In contrast, it installing haveged to dom0 might have better benefits at lower cost:

• This seems to be much less work.
• Haveged should help with collecting entropy in early stages, when it is needed the most.
• Haveged can increase entropy estimate. When you seed from DomUs, you should never do this, for obvious reasons.

If I understand correctly the Linux RNG design, it should be enough to seed it with unique 32 bytes of entropy and it should produce random-enough data virtually forever, unless the RNG state is leaked or cloned. That's the reason why seeding from DomUs will IMHO provide entropy when it is rather irrelevant.

[v6ak]

Transferring entropy from DomUs to dom0 looks crazy. Theoretically, there is nothing wrong with this (unless entropy estimate is increased by this operation), but I feel this to be strange. Moreover, there are some design considerations, like how frequently this should occur.

In contrast, it installing haveged to dom0 might have better benefits at lower cost:

• This seems to be much less work.
• Haveged should help with collecting entropy in early stages, when it is needed the most.
• Haveged can increase entropy estimate. When you seed from DomUs, you should never do this, for obvious reasons.

If I understand correctly the Linux RNG design, it should be enough to seed it with unique 32 bytes of entropy and it should produce random-enough data virtually forever, unless the RNG state is leaked or cloned. That's the reason why seeding from DomUs will IMHO provide entropy when it is rather irrelevant.

[ag4ve]

On Feb 16, 2016 5:50 AM, "cfcs" notifications@github.com wrote:

Alternatively the VMs could regularly feed entropy back to dom0

If the goal is minimal trust in apps, this is a horrible idea. Ie, don't
use a RNG you don't fully trust.

[ag4ve]

On Feb 16, 2016 5:50 AM, "cfcs" notifications@github.com wrote:

Alternatively the VMs could regularly feed entropy back to dom0

If the goal is minimal trust in apps, this is a horrible idea. Ie, don't
use a RNG you don't fully trust.

[v6ak]

Adding additional seed to your RNG from untrusted sources is not an issue. Unless there is something fundamentally broken with the RNG reseeding mechanism, such sources can only increase RNG entropy, but they can never decrease it. (I assume that RNG state remains private. But if it does not, there are larger troubles…)

So, I don't think it is broken idea. It is IMHO just too much effort for non-adequate benefits.

[v6ak]

Adding additional seed to your RNG from untrusted sources is not an issue. Unless there is something fundamentally broken with the RNG reseeding mechanism, such sources can only increase RNG entropy, but they can never decrease it. (I assume that RNG state remains private. But if it does not, there are larger troubles…)

So, I don't think it is broken idea. It is IMHO just too much effort for non-adequate benefits.

[adrelanos]

Please create a separate discussion for the "feed entropy back from VMs to dom0" because it is totally different from this "persist random seed files [entropy] in TemplateBasedVMs".

[adrelanos]

Please create a separate discussion for the "feed entropy back from VMs to dom0" because it is totally different from this "persist random seed files [entropy] in TemplateBasedVMs".

[cfcs]

@ag4ve I would seed it once, at boot, and let haveged collect from there.

On shutdown I would opportunistically transfer the seed file back into /dev/random - this should not deteriorate the entropy pool of a CSPRNG. If it does, /dev/random is flawed.

[cfcs]

@ag4ve I would seed it once, at boot, and let haveged collect from there.

On shutdown I would opportunistically transfer the seed file back into /dev/random - this should not deteriorate the entropy pool of a CSPRNG. If it does, /dev/random is flawed.

[adrelanos]

Vít Šesták:

Note that just moving random seed to /rw would not solve the problem
fully, because /rw gets cloned when a new VM is created, so some
information about template would be maybe leaked in such case.

This ticket is about TemplateBasedVMs only. So cloning them is not
supported.

DispVMs are based on the TemplateVM, not TemplateBasedVM. A DispVM
started by a TemplateBasedVM therefore should not be able to read the
random seed file of the TemplateBasedVM that started it.

Alternatively, when the filesystem relocates the random seed
after boot, the attacker might even find the original random seed.

Why would that be a problem?

[adrelanos]

Vít Šesták:

Note that just moving random seed to /rw would not solve the problem
fully, because /rw gets cloned when a new VM is created, so some
information about template would be maybe leaked in such case.

This ticket is about TemplateBasedVMs only. So cloning them is not
supported.

DispVMs are based on the TemplateVM, not TemplateBasedVM. A DispVM
started by a TemplateBasedVM therefore should not be able to read the
random seed file of the TemplateBasedVM that started it.

Alternatively, when the filesystem relocates the random seed
after boot, the attacker might even find the original random seed.

Why would that be a problem?

[v6ak]

I have just noted two facts:

1. This issue is handled in some other way, i.e. by seeding from dom0.
2. Your proposed solution is not perfect. It might sometimes produce weaker results than you might expect.

You seem to comment the second one only. The issue is that there are some scenarios when you clone /rw, which might cause RNG seed to be reused. These scenarios include:

• You clone a TemplateVM (obvious).
• You clone a TemplateBasedVM (obvious).
• You create a new TemplateBasedVM. (In this case, /rw is cloned from the template to the VM.)
• You start a DVM. (But in fact, the current DVM implementation handles RNG very differently. It is, however, AFAIK planned to change this behavior and make DVMs more like regular VMs.)

When you seed multiple VMs bythe same seed, you obviously get somewhat suboptimal results. If seeding is redundant (my note no. 1), then you don't break anything (maybe except clarity of the code, which might result in an issue caused by some future code modification), but if seeding is essential, you might allow some attacks by this behavior.

My complaint about issues caused by relocation is an extension of these issues. When attacker gets the random seed you have used, you essentially lose all the advantages over the attacker you had.

I am not saying that you approach is completely wrong. I am just noting that there are some potential issues.

[v6ak]

I have just noted two facts:

1. This issue is handled in some other way, i.e. by seeding from dom0.
2. Your proposed solution is not perfect. It might sometimes produce weaker results than you might expect.

You seem to comment the second one only. The issue is that there are some scenarios when you clone /rw, which might cause RNG seed to be reused. These scenarios include:

• You clone a TemplateVM (obvious).
• You clone a TemplateBasedVM (obvious).
• You create a new TemplateBasedVM. (In this case, /rw is cloned from the template to the VM.)
• You start a DVM. (But in fact, the current DVM implementation handles RNG very differently. It is, however, AFAIK planned to change this behavior and make DVMs more like regular VMs.)

When you seed multiple VMs bythe same seed, you obviously get somewhat suboptimal results. If seeding is redundant (my note no. 1), then you don't break anything (maybe except clarity of the code, which might result in an issue caused by some future code modification), but if seeding is essential, you might allow some attacks by this behavior.

My complaint about issues caused by relocation is an extension of these issues. When attacker gets the random seed you have used, you essentially lose all the advantages over the attacker you had.

I am not saying that you approach is completely wrong. I am just noting that there are some potential issues.

[unman]

@adrelanos Since we are now seeding from dom0 is there any point in keeping this open? Is it a better solution, and if so, why?

[unman]

@adrelanos Since we are now seeding from dom0 is there any point in keeping this open? Is it a better solution, and if so, why?

[adrelanos]

Yes, I am still for persisting those entropy seed files. In the worst case, it does no harm. Entropy being added that was leaked elsewhere in combination with the existing dom0 -> VM seeding does not make things worse.

In the best case we are closer to what other distributions are doing. Would get better entropy by reusing the persisted entropy file plus the dom0 -> VM seeding.

[adrelanos]

Yes, I am still for persisting those entropy seed files. In the worst case, it does no harm. Entropy being added that was leaked elsewhere in combination with the existing dom0 -> VM seeding does not make things worse.

In the best case we are closer to what other distributions are doing. Would get better entropy by reusing the persisted entropy file plus the dom0 -> VM seeding.

[adrelanos]

After creating a TemplateBasedVM it would share the TemplateVM seed for a shorter period of time. Not at every boot.

The easy solution would be to just add these files to bind-dirs. Another iteration could be to delete these files on first boot after cloning in the cloned VM.

[adrelanos]

After creating a TemplateBasedVM it would share the TemplateVM seed for a shorter period of time. Not at every boot.

The easy solution would be to just add these files to bind-dirs. Another iteration could be to delete these files on first boot after cloning in the cloned VM.