Ask to create default policy for new qrexec services?

[rootkovska]

In 3.2 if the user creates a new qrexec service (for which there is no policy file in dom0), we get a window asking to create the default policy for the service. In 4.0-rc1 we get connection refusal if the policy is missing.

[marmarek]

Since now we have new qrexec prompt window - which is harder to accidentally accept, what do you think about applying default policy "$anyvm $anyvm ask", without asking first?

[marmarek]

Since now we have new qrexec prompt window - which is harder to accidentally accept, what do you think about applying default policy "$anyvm $anyvm ask", without asking first?

[rootkovska]

+1

[rootkovska]

+1

[marmarek]

On the other hand, this would allow VM existence confirmation, which may be privacy issue. So, I'll implement explicit confirmation, as it was in 3.2.

[marmarek]

On the other hand, this would allow VM existence confirmation, which may be privacy issue. So, I'll implement explicit confirmation, as it was in 3.2.

[rootkovska]

Why would it allow VM existence confirmation any better?

[rootkovska]

Why would it allow VM existence confirmation any better?

[marmarek]

Because when target domain specified by source domain does not exist, the call will be rejected (not existing domain does not match with $anyvm, so ask action will not be applied).

[marmarek]

Because when target domain specified by source domain does not exist, the call will be rejected (not existing domain does not match with $anyvm, so ask action will not be applied).

[rootkovska]

But... here we're discussing non-existing services?

[rootkovska]

But... here we're discussing non-existing services?

[marmarek]

Yes. And when you automatically get $anyvm $anyvm ask policy, it allows exactly what I've described above. That's why I prefer to ask before policy creation (before even looking at target domain).

[marmarek]

Yes. And when you automatically get $anyvm $anyvm ask policy, it allows exactly what I've described above. That's why I prefer to ask before policy creation (before even looking at target domain).

[rootkovska]

Is there anything fundamental that prevents us from not dropping the call before we display the window? Or perhaps adding a random delay in case non-existing target?

[rootkovska]

Is there anything fundamental that prevents us from not dropping the call before we display the window? Or perhaps adding a random delay in case non-existing target?

[rootkovska]

(Random delay simulating the user reading and click on the dialog)

[rootkovska]

(Random delay simulating the user reading and click on the dialog)

[marmarek]

Is there anything fundamental that prevents us from not dropping the call before we display the window?

Can you rephrase? We are actually dropping the call before displaying the window.

Note that the "problem" is not "ask" action rejecting non-existing target, but not applying "ask" action at all (so it gets to implicit deny, because no rule have matched).

As for random delay - I think it may break many legitimate use cases... And getting it right will be really hard - for example we need to assume some range, and it should match how much this particular user spends on reading the dialog.

IMO one time ask before policy creation, at the first service call is much simpler solution - both in terms of implementation and usability.

[marmarek]

Is there anything fundamental that prevents us from not dropping the call before we display the window?

Can you rephrase? We are actually dropping the call before displaying the window.

Note that the "problem" is not "ask" action rejecting non-existing target, but not applying "ask" action at all (so it gets to implicit deny, because no rule have matched).

As for random delay - I think it may break many legitimate use cases... And getting it right will be really hard - for example we need to assume some range, and it should match how much this particular user spends on reading the dialog.

IMO one time ask before policy creation, at the first service call is much simpler solution - both in terms of implementation and usability.

[marmarek]

Can you rephrase? We are actually dropping the call before displaying the window.

Ah, there is "not". Ok, so ignore this and read the rest of my comment.

[marmarek]

Can you rephrase? We are actually dropping the call before displaying the window.

Ah, there is "not". Ok, so ignore this and read the rest of my comment.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.6-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.6-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.11-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.11-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update