split-gpg keeps asking for target VM when it shouldn't need to

[Elias Mårtenson]

I'm using split-gpg, and I end up using it a lot since I sign my git commits using it.

Since upgrading to 4.0rc2, I have noticed that every time a VM wants to call out to the GPG VM,

a dialog box is shown asking me for the target VM. At this point I need to click on the menu

and manually choose the GPG VM, even though the name of that VM is already specified

in the QUBES_GPG_DOMAIN environment variable.

Is this a bug?

Regards,

Elias

[Jean-Philippe Ouellet]

It's an effect of https://github.com/QubesOS/qubes-issues/issues/910

Explicitly allowing it in policy e.g.
some-vm some-vm-keys allow
in /etc/qubes-rpc/policy/qubes.Gpg will stop asking for confirmation each time.

Technically QUBES_GPG_DOMAIN isn't required anymore if each VM only
has at most one corresponding split-gpg VM, as you could configure the
target with:
some-vm $anyvm allow,target=some-vm-keys

[Jean-Philippe Ouellet]

Perhaps this is an indication that the dialog should have an
additional "remember this target and allow future requests" (or
similar) option.

[Elias Mårtenson]

On Friday, 24 November 2017 12:10:06 UTC+8, Jean-Philippe Ouellet wrote:

 

Explicitly allowing it in policy e.g.
    some-vm    some-vm-keys    allow
in /etc/qubes-rpc/policy/qubes.Gpg will stop asking for confirmation each time.

Thank you.

Adding “$anyvm private-gpg allow” to the file fixed the problem.

Regards,

Elias 

[Jean-Philippe Ouellet]

No! I would very strongly recommend against that!

That allows any VM (including entirely untrusted ones, like sys-net,
DispVMs with who knows what, etc.) to sign & decrypt stuff with your
keys!

Use a specific source vm in the first field, not $anyvm, otherwise you
may actually be better off without split-gpg entirely depending on
your threat model.

Regards,
Jean-Philippe

[Elias Mårtenson]

On Friday, 24 November 2017 14:39:26 UTC+8, Jean-Philippe Ouellet wrote:

 

No! I would very strongly recommend against that!

That allows any VM (including entirely untrusted ones, like sys-net,
DispVMs with who knows what, etc.) to sign & decrypt stuff with your
keys!

Use a specific source vm in the first field, not $anyvm, otherwise you
may actually be better off without split-gpg entirely depending on
your threat model.

I still get the notification asking me to allow the signing. With the line added, the

behaviour seems to be identical to what I had in 3.2.

Regards,

Elias

[Elias Mårtenson]

I do agree with you in the general case, that locking things are better than not

locking them. In this particular case, however, I want almost all my VM's to be

able to sign at one point or the other. And this behaviour was deemed acceptable

in 3.2, so I don't really see how my solution can be seen as being overly bad?

Regards,

Elias

[Jean-Philippe Ouellet]

On Fri, Nov 24, 2017 at 1:50 AM, Elias Mårtenson <lok...@gmail.com> wrote:
> On Friday, 24 November 2017 14:46:47 UTC+8, Elias Mårtenson wrote:
>>
>> On Friday, 24 November 2017 14:39:26 UTC+8, Jean-Philippe Ouellet wrote:
>>
>>>
>>> Use a specific source vm in the first field, not $anyvm, otherwise you
>>> may actually be better off without split-gpg entirely depending on
>>> your threat model.
>>
>>
>> I still get the notification asking me to allow the signing. With the line
>> added, the
>> behaviour seems to be identical to what I had in 3.2.
>
>
> I do agree with you in the general case, that locking things are better than
> not
> locking them. In this particular case, however, I want almost all my VM's to
> be
> able to sign at one point or the other.

...but surely not *all* of them able to do perform any operation they
want on any data they want using any key they want as soon as you
authorize it once for any VM! (by default the agent authorizes any use
of the keyring for 300 seconds(?) after first use)

> And this behaviour was deemed acceptable
> in 3.2, so I don't really see how my solution can be seen as being overly
> bad?

No, I can assure you it was not acceptable in 3.2 either. The only
legitimate use I can think of is perhaps if you only have public keys
in that VM and used it as some kind of poor-mans key-distribution
system... but even that is a stretch.

Was there some documentation you got this from? If so, please do point
me to it so I can correct it ASAP.

Regards,
Jean-Philippe

[Elias Mårtenson]

On Friday, 24 November 2017 15:05:27 UTC+8, Jean-Philippe Ouellet wrote:

 

...but surely not *all* of them able to do perform any operation they
want on any data they want using any key they want as soon as you
authorize it once for any VM! (by default the agent authorizes any use
of the keyring for 300 seconds(?) after first use)

Yes, 300 seconds is the default. And it's only authorised for a given VM. Trying to sign

from another VM will present the popup again.

As long as I don't accept the GPG warning popup unless I know it's OK, I don't see

this as an issue. Also, every signing request during these 300 seconds will display a

notification, which will quickly reveal if there are any strange things happening (and,

again, I'd need to manually authorise the first access anyway).

 

Was there some documentation you got this from? If so, please do point
me to it so I can correct it ASAP.

When I initially did this for 3.2, I followed the official documentation on this, which gave

me the configuration that is identical to what I managed to set up with 4.0 now:

https://www.qubes-os.org/doc/split-gpg/

There are no mentions of limiting access to specific VM's, and the following statement

seems pretty reasonable to me:

    “With Qubes Split GPG this problem is drastically minimized, because each time the key

    is to be used the user is asked for consent (with a definable time out, 5 minutes by default),

    plus is always notified each time the key is used via a tray notification from the domain

    where GPG backend is running. This way it would be easy to spot unexpected requests

    to decrypt documents.”

The attack scenario you describe just doesn't seem as serious to me as it does to you. This

scenario would involve a rogue application calling qubes-gpg-client to attempt to sign some

data, and somehow manage to trick me into accepting the request.

Regards,

Elias

[Jean-Philippe Ouellet]

On Fri, Nov 24, 2017 at 2:27 AM, Elias Mårtenson <lok...@gmail.com> wrote:
> On Friday, 24 November 2017 15:05:27 UTC+8, Jean-Philippe Ouellet wrote:
>
>>
>> ...but surely not *all* of them able to do perform any operation they
>> want on any data they want using any key they want as soon as you
>> authorize it once for any VM! (by default the agent authorizes any use
>> of the keyring for 300 seconds(?) after first use)
>
>
> Yes, 300 seconds is the default. And it's only authorised for a given VM.
> Trying to sign from another VM will present the popup again.

Ah, indeed. Having only ever had 1:1 some-vm:some-vm-gpg pairs I had
not realized this was the case. I apologize.

> As long as I don't accept the GPG warning popup unless I know it's OK, I
> don't see
> this as an issue. Also, every signing request during these 300 seconds will
> display a
> notification, which will quickly reveal if there are any strange things
> happening (and,
> again, I'd need to manually authorise the first access anyway).
>
>>
>> Was there some documentation you got this from? If so, please do point
>> me to it so I can correct it ASAP.
>
>
> When I initially did this for 3.2, I followed the official documentation on
> this, which gave
> me the configuration that is identical to what I managed to set up with 4.0
> now:
> https://www.qubes-os.org/doc/split-gpg/

That documentation never suggests a policy of allowing from any vm.
The old policy accept gui it has a screenshot of (when saying "Yes to
All") modifies policy to allow *only the specific src/dest pair* for
future requests.

> There are no mentions of limiting access to specific VM's, and the following
> statement
> seems pretty reasonable to me:
>
> “With Qubes Split GPG this problem is drastically minimized, because
> each time the key
> is to be used the user is asked for consent (with a definable time out,
> 5 minutes by default),
> plus is always notified each time the key is used via a tray
> notification from the domain
> where GPG backend is running. This way it would be easy to spot
> unexpected requests
> to decrypt documents.”
>
> The attack scenario you describe just doesn't seem as serious to me as it
> does to you. This
> scenario would involve a rogue application calling qubes-gpg-client to
> attempt to sign some
> data, and somehow manage to trick me into accepting the request.

Well, of course you're welcome to do whatever you'd like. Just don't
say I didn't warn you :)

Regards,
Jean-Philippe

[Leo Gaspard]

On 11/24/2017 08:27 AM, Elias Mårtenson wrote:
> The attack scenario you describe just doesn't seem as serious to me as
> it does to you. This
> scenario would involve a rogue application calling qubes-gpg-client to
> attempt to sign some
> data, and somehow manage to trick me into accepting the request.

I believe the threat Jean-Philippe is describing is something like:
* You use an untrusted VM to perform some GPG operation
* However it was infected and something was waiting for you to accept this
* This something can now perform any GPG operation they want during
300s using your secret keys

Which is an argument against using split GPG from untrusted domains. And
this argument against using split GPG from untrusted domains then
naturally encourages the policy to actually disallow using split GPG
from untrusted domains, instead of allowing it. Even leaving the default
“ask” operation it means you have to misthink twice in order to let an
untrusted VM access your keyring, including once with an unusual popup
(as the policy for your frequently-signing VMs will already be set to
“allow” by clicking the “allow for all” button); so it's better than
having “$anyvm split-gpg allow”.

[Elias Mårtenson]

On Saturday, 25 November 2017 09:03:42 UTC+8, Leo Gaspard wrote:
> On 11/24/2017 08:27 AM, Elias Mårtenson wrote:
> > The attack scenario you describe just doesn't seem as serious to me as
> > it does to you. This
> > scenario would involve a rogue application calling qubes-gpg-client to
> > attempt to sign some
> > data, and somehow manage to trick me into accepting the request.
>
> I believe the threat Jean-Philippe is describing is something like:
> * You use an untrusted VM to perform some GPG operation
> * However it was infected and something was waiting for you to accept this
> * This something can now perform any GPG operation they want during
> 300s using your secret keys

Yes. I don't think we're in disagreement about the thread model.
Even in the case you're describing I would still know that something
is singing things on my behalf as every signing operation will display
a notification.

That said, the 300s unlock time isn't particularly beneficial to me, and
I will probably set it to something significantly lower, like 1 second
or even 0.

Regards,
Elias