Make an AppVM act as a gpg smartcard

[Micah Lee]

I'd like to create a networkless AppVM that has a gpg secret key in it. Other AppVMs can have gpg keyrings with public keys, as well as gpg-agent. When they want to do secret key operations, they can go through gpg-agent to talk to the AppVM with the secret key. So if my Thunderbird AppVM gets compronised, it could do decrypt/sign operations, but it couldn't get a copy of my actual secret key. Basically, exactly how physical gpg smartcards work except inside of Qubes.

I envision it working by going through some software running in dom0, rather than networking, so we don't need to worry about a hacked netvm (or maintaining iptables rules). And maybe each AppVM can let you set a smartcardvm, the same way you can set a netvm.

Has anyone put any work into something like this?

Sent from my personal tracking device. 

[Marek Marczykowski-Górecki]

You are basically talking about this:
http://wiki.qubes-os.org/trac/ticket/474

There is simpler version already implemented (qubes-gpg-split package), but it
relay whole gpg processing to the selected VM, so also public keyring needs to
be there.

> Sent from my personal tracking device.

:)

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Joanna Rutkowska]

On 04/30/14 21:49, Marek Marczykowski-Górecki wrote:
> On 30.04.2014 19:49, Micah Lee wrote:
>> I'd like to create a networkless AppVM that has a gpg secret key in it. Other AppVMs can have gpg keyrings with public keys, as well as gpg-agent. When they want to do secret key operations, they can go through gpg-agent to talk to the AppVM with the secret key. So if my Thunderbird AppVM gets compronised, it could do decrypt/sign operations, but it couldn't get a copy of my actual secret key. Basically, exactly how physical gpg smartcards work except inside of Qubes.
>>
>> I envision it working by going through some software running in dom0, rather than networking, so we don't need to worry about a hacked netvm (or maintaining iptables rules). And maybe each AppVM can let you set a smartcardvm, the same way you can set a netvm.
>>
>> Has anyone put any work into something like this?
>
> You are basically talking about this:
> http://wiki.qubes-os.org/trac/ticket/474
>
> There is simpler version already implemented (qubes-gpg-split package), but it
> relay whole gpg processing to the selected VM, so also public keyring needs to
> be there.
>

And it uses qrexec to communicate, rather than "some software running in
dom0" :) Ok, ok, in Qubes R2 the qrexec connection actually goes through
Dom0, but what I want to say is that doing what you're asking for should
really be simple as all the building blocks (qrexcec infrastructure) is
already in place. So, if you happen to be familiar with gpg v2
architecture, then it should be really easy for you to implement exactly
what you're describing above and what, incidentally, constitutes the
above mentioned ticket.

For a primer on using qrexec to write "Qubes apps" see this article:

http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

One thing that might not be immediately obvious is that it is easy to
make the "gpg backend" to display a prompt dialog box every time (or
every n times) it is asked by the client to do encryption/signing. So,
this split GPG thing has actually a big advantage over the use of a
traditional Smart Card, as in case of the Smart Card a compromised
Thunderbird can just "ask" it to decrypt all your 1000 emails and you
will likely not even notice that (this assumes the user keeps his or her
card inserted for quite some time). In case of Split GPG on Qubes this
could be trivially spotted/prevented.

joanna.

[Micah Lee]

Interesting. Before I try building my own thing like this, I'm going to
try to get qubes-gpg-split working. As far as I can tell there's no
documentation besides this [1]?

I've managed to follow those instructions and get it working fine for
gpg from the command line, but enigmail is another story. In enigmail I
can go to OpenPGP > Preferences and set my gpg binary to be
/bin/qubes-gpg-client, but it doesn't work. I then wrote a bash wrapper
script that logs what options are being sent and tried it again.

This is what it tries to run when I attempt to encrypt an email to myself:

qubes-gpg-client --charset utf-8 --display-charset utf-8 --batch
--no-tty --status-fd 2 --comment Using GnuPG with Thunderbird -
http://www.enigmail.net/ -a -t --encrypt --sign --always-trust
--encrypt-to 0x99999697 -r <mica...@theintercept.com> -u 0x99999697
--use-agent

I think all enigmail gpg calls use --batch. When you use gpg in batch
mode it takes in input from STDIN instead of parameters, which probably
isn't supported with qubes-gpg-client?

Has anyone else gotten this to work with enigmail?

[1] https://groups.google.com/forum/#!topic/qubes-users/UEtyxODIBlY

--
Micah Lee

[Marek Marczykowski-Górecki]

This isn't a problem, --batch is supported. It worked with enigmail some time
ago. But "--display-charset" and "--always-trust" options aren't whitelisted
(probably added in some newer enigmail version). I've uploaded updated package
to unstable repository:
sudo yum install --enablerepo=qubes-vm-r2-unstable qubes-gpg-split

You need also QUBES_GPG_DOMAIN env variable (but you probably already know this).

> Has anyone else gotten this to work with enigmail?
>
> [1] https://groups.google.com/forum/#!topic/qubes-users/UEtyxODIBlY
>


--

[Micah Lee]

On 04/30/14 21:58, Marek Marczykowski-Górecki wrote:
> This isn't a problem, --batch is supported. It worked with enigmail some time
> ago. But "--display-charset" and "--always-trust" options aren't whitelisted
> (probably added in some newer enigmail version). I've uploaded updated package
> to unstable repository:
> sudo yum install --enablerepo=qubes-vm-r2-unstable qubes-gpg-split
>
> You need also QUBES_GPG_DOMAIN env variable (but you probably already know this).
>

I'm using the new qubes-gpg-split package, but it's still not working.

When I open OpenPGP > Key Management in enigmail I get this error:

Error - encryption command failed
/home/user/gpg-qubes --charset utf-8 --display-charset utf-8 --use-agent
--no-tty --batch --no-tty --status-fd 2 --with-fingerprint
--fixed-list-mode --with-colons --list-secret-keys
ERROR: Destination domain not defined! Set it with QUBES_GPG_DOMAIN env
variable.

I tried to set QUBES_GPG_DOMAIN in /etc/profile.d/qubes_gpg.sh. Is there
some other place I should set it so that the subprocesses launched by
enigmail have that environment too?

[user@email ~]$ echo $QUBES_GPG_DOMAIN
gpgvm
[user@email ~]$ cat /etc/profile.d/qubes_gpg.sh
#### Setting for client vm ####
# VM with GPG server
export QUBES_GPG_DOMAIN="gpgvm"
alias gpg='qubes-gpg-client --use-agent --no-tty'


#### Settings for GPG VM ####
# Remember user choice for this many seconds - default 5min (300s)
#export QUBES_GPG_AUTOACCEPT=300


Also, most of the time it seems to just fail silently and not give that
error. When I set my gpg path to my wrapper script that logs what
commands are being called, those commands seem to work from the command
line but not from thunderbird. So I suspect that this might just be an
environment variable problem.

--
Micah Lee

[Micah Lee]

I'm still trying to figure out how to make enigmail work with
qubes-gpg-client.

I have set the QUBES_GPG_DOMAIN environment variable in
/etc/profile.d/qubes_gpg.sh:

[user@email ~]$ cat /etc/profile.d/qubes_gpg.sh
#### Setting for client vm ####
# VM with GPG server
export QUBES_GPG_DOMAIN="gpgvm"
alias gpg='qubes-gpg-client --use-agent --no-tty'


#### Settings for GPG VM ####
# Remember user choice for this many seconds - default 5min (300s)
#export QUBES_GPG_AUTOACCEPT=300

I can run gpg commands from the command line fine, and when I do it pops
up a window in dom0 asking if I want to let my email AppVM talk to my gpgvm.

But nothing is working in thunderbird/enigmail when I set my gpg binary
to be /bin/qubes-gpg-client. When I first open thunderbird I get this error:

Enigmail: Error in accessing Enigmail service

To permanently avoid this alert, either fix the problem or uninstall
Enigmail. Click on the Help button for more details.

When I open Key Management in enigmail I get this error:

Error - encryption command failed

/bin/qubes-gpg-client --charset utf-8 --display-charset utf-8

--use-agent --no-tty --batch --no-tty --status-fd 2 --with-fingerprint

--fixed-list-mode --with-colons --list-keys

ERROR: Destination domain not defined! Set it with QUBES_GPG_DOMAIN env
variable.

So it looks like, for whatever reason, enigmail isn't able to see that
QUBES_GPG_DOMAIN is set, and that could be the problem. Is there a
better place to set this environment variable than
/etc/profile.d/qubes_gpg.sh? Thanks!

--
Micah Lee

[Vincent Penquerc'h]

On 06/05/14 07:09, Micah Lee wrote:
> Error - encryption command failed /bin/qubes-gpg-client --charset
> utf-8 --display-charset utf-8 --use-agent --no-tty --batch --no-tty
> --status-fd 2 --with-fingerprint --fixed-list-mode --with-colons
> --list-keys ERROR: Destination domain not defined! Set it with
> QUBES_GPG_DOMAIN env variable.
>
> So it looks like, for whatever reason, enigmail isn't able to see
> that QUBES_GPG_DOMAIN is set, and that could be the problem. Is
> there a better place to set this environment variable than
> /etc/profile.d/qubes_gpg.sh? Thanks!

Maybe you could set your gpg to /usr/local/qubes-gpg-client-enigmail,
which might contain something like:

#!/bin/sh
export QUBES_GPG_DOMAIN=$domainname
exec /bin/qubes-gpg-client "$@"

Or something similar as a workaround.

[Marina Brown]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Would it be possible to have a template do all this ?
Thunderbird/enigmail is kind of essential for many of us.

- --- Marina
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQQcBAEBAgAGBQJTaOFVAAoJEGFB2/L+HHT1/nYf+gJKb4pL5GPYl/z281SVV/1J
MWw8Lo1wEBpdUOjU3P5ZYYAk4NuxFwJE9a5fnXeotv3249LEVN9G2aVglpuEHSDE
6ZZX3XJFL5r2dMtIKMhVS4QFheKUxEaiMTAKshqE0q0wvRiWG0g7PofOELmr0MK2
P5cEDeyWRj6zWUpuYmF+TDwLdUe6/f23K3aK989TLt43PKz0zXvRTxn76ARm6z4e
jx30+dqqUmHFCcG+WN3HhMv3h6p7kIwuBQgXqhCaMMfjYPkYeMD2hGi23L3FnK09
+JFW1oR1QJGFV9EGff7IcXYwtKjFgQheolR5WIgeUElDCpIDfL8YzbkB4RlIZHqn
0EzBoJh0cPFDP/rl4unXOaVhjXONQsxJrURw4nPEZXS3OPwwDYBvv1PgN/1ADchj
i5OlwxhrPuec6hPpt2ldTW/RpeNvTR+6/hy84gjAoAtq0KWQ06AThhFaEopxp351
RnGuDndBh4/D/jMTF7uVIn+ktgbBoza8vzVDkhdhr85tdKY/d250jPBbXrRLO/kH
1EJIf9kFbwgn5NOO2wmYjjeRWaIZ51bK4xqBdQDrWEtPKXx1RR22xqlwouQ0aQ9N
aK19Ehj0VPmhMIAmxSQms+I9xGOI8m9FgsH20Pv5oXpCLsXroEDIak56nTP+OVAV
KtjaaOs3bQb1oBrpe7R0hH0XgksqK3ZI2E+vaW7RA11VTPi5x9PpXWkgtt0KTejM
eoSoGybJDlpubNNWyZ+yEsV/+xuH5L8mTU5WBn7rqIAemZpk+3RZUNvHhWHAbjfi
bfj+NBywo8Bgol6KTehtPhwilu39cnZpKRtlfDN7msw4wYUN9C3qDY7/7OpQJget
DdE3QhmXgfRu92S8MqObiilnVZeBWzzquSRi7BI3yg7JJNC35Imp9T9f5ySSOoNs
Sx9iEgodLvvTyhrZEtFhCAXUCl0584Y/1q561eFqclh6sba5wHfIDh0xg/XKP/z+
JKk8YeAHMVk5AIH8fEXEl+uVAeWj1l58sYG5xO/pCo7OP6jh7UNnJTkGetXArA2P
aOQJK9Ydh2cMg45QHFE88zzzciAuqpzj0v2KbbcGg729q/Q1wBOx0YY83rk2EwRX
/eI3zbsfyCETrfdPMCchBCOf/5GbH8mH8dBVrZTVc32ntHMeYjtnSV4fAfACkVIQ
Z5MjDvtW/jpT2xi7d6s0jFRTqMkuwEJ6cEF81HOnyeC3q1LZpwvyDroaOS7WltnF
HQLdNGYeuTvIS3YgT9FC9kGtfdgK4b9ikm7lTMSq79IR89FUS0ww5neiqEqPzaxS
Ay8y2Eyz3JPro3jFPD14TfJDbYR1XZY/ZupxpBHfpB7+HBeJqyS6U6OXWScCusk=
=XL65
-----END PGP SIGNATURE-----

[Micah Lee]

On 05/06/14 03:28, Vincent Penquerc'h wrote:
> Maybe you could set your gpg to /usr/local/qubes-gpg-client-enigmail,
> which might contain something like:
>
> #!/bin/sh
> export QUBES_GPG_DOMAIN=$domainname
> exec /bin/qubes-gpg-client "$@"
>
> Or something similar as a workaround.

Thanks Vincent, this totally seems to work! At least, much better than
before. I can decrypt emails now, and it requires me to verify that I
want to let email talk to gpgvm.

One problem I'm having is, once I verify it it pops up a window from
gpgvm saying: "Do you allow VM 'email' to access your GPG keys (now and
for the following 300 seconds)?"

It works when I choose yes, but it doesn't seem to be caching this
decision for 300 seconds. It asks every single time, which ends up being
a lot of boxes to click through to do anything with enigmail.

Also, it looks like --list-secret-keys isn't implemented in
qubes-gpg-client. When I open enigmail's Key Management, I get this error:

Error - encryption command failed

/home/user/qubes-gpg-client-enigmail --charset utf-8 --display-charset

utf-8 --use-agent --no-tty --batch --no-tty --status-fd 2

--with-fingerprint --fixed-list-mode --with-colons --list-secret-keys
/bin/qubes-gpg-client: unrecognized option '--list-secret-keys'

Was this on purpose? I don't see any security problems with listing
secret keys, as long as --export-secret-keys and --export-secret-subkeys
don't work.

Also, I'm not able to send emails that are just signed by not encrypted.
When I try, I get this error in an OpenPGP Alert window:

Error - encryption command failed

But it's exciting that it finally works (somewhat) with enigmail.

Once these issues are worked out I'd be interested in writing a wiki
page describing how to set this up.

--
Micah Lee

[Micah Lee]

Now that I'm using enigmail a bit more, I'm noticing other issues as well.

If there are emails that are signed but not encrypted, it doesn't seem
to work to verify the sigs. The permission boxes pop up and click yes,
but it doesn't actually get to verifying, perhaps because enigmail
expects a response faster.

I've also noticed that enigmail tends to call several gpg subprocesses
at a time when dealing with a single email. This means that the
permission box pops up over and over again. It's so annoying that I
decided to click "Yes to All" for this VM, but that decision doesn't
seem to persist, since the box still pops up.

It's not quite working yet, but if I ever want to undo my "Yes to All"
setting in the future, where can I do that?

--
Micah Lee

[Vincent Penquerc'h]

On 05/06/14 18:59, Micah Lee wrote:
> It's not quite working yet, but if I ever want to undo my "Yes to All"
> setting in the future, where can I do that?

I think you can just remove the appropriate line in
/etc/qubes-rpc/policy/qubes.Gpg (or similarly named). It defaults to asking.

[Marek Marczykowski-Górecki]

This last issue is one probably already fixed in upcoming 2.0.3 package (there
was a bug which cut off the last char of cmdline...). This can also be a
reason for failed encryption.

>>
>> But it's exciting that it finally works (somewhat) with enigmail.
>>
>> Once these issues are worked out I'd be interested in writing a wiki
>> page describing how to set this up.
>>
>
> Now that I'm using enigmail a bit more, I'm noticing other issues as well.
>
> If there are emails that are signed but not encrypted, it doesn't seem
> to work to verify the sigs. The permission boxes pop up and click yes,
> but it doesn't actually get to verifying, perhaps because enigmail
> expects a response faster.
>
> I've also noticed that enigmail tends to call several gpg subprocesses
> at a time when dealing with a single email. This means that the
> permission box pops up over and over again. It's so annoying that I
> decided to click "Yes to All" for this VM, but that decision doesn't
> seem to persist, since the box still pops up.

There are two level of confirmation:
1. Generic Qubes RPC one (yes/no/yes to all).
2. Gpg for given domain with timeout (yes/no).

"Yes to all" in the first one will modify RPC policy in dom0
(/etc/qubes-rpc/policy). If this doesn't work, check file permissions (should
be writable by qubes group).

>
> It's not quite working yet, but if I ever want to undo my "Yes to All"
> setting in the future, where can I do that?
>


--

[Micah Lee]

On 05/06/14 14:09, Marek Marczykowski-Górecki wrote:
> On 06.05.2014 19:59, Micah Lee wrote:
>>> Also, I'm not able to send emails that are just signed by not encrypted.
>>> When I try, I get this error in an OpenPGP Alert window:
>>>
>>> Error - encryption command failed
>
> This last issue is one probably already fixed in upcoming 2.0.3 package (there
> was a bug which cut off the last char of cmdline...). This can also be a
> reason for failed encryption.

Oh great. When will it be in the unstable repo so I can upgrade? I can't
wait for this to work better.

>> I've also noticed that enigmail tends to call several gpg subprocesses
>> at a time when dealing with a single email. This means that the
>> permission box pops up over and over again. It's so annoying that I
>> decided to click "Yes to All" for this VM, but that decision doesn't
>> seem to persist, since the box still pops up.
>
> There are two level of confirmation:
> 1. Generic Qubes RPC one (yes/no/yes to all).
> 2. Gpg for given domain with timeout (yes/no).
>
> "Yes to all" in the first one will modify RPC policy in dom0
> (/etc/qubes-rpc/policy). If this doesn't work, check file permissions (should
> be writable by qubes group).

I have both /etc/qubes-rpc and /etc/qubes_rpc.

In /etc/qubes_rpc/policy there's qubes.Gpg and qubes.PdfConvert, both
writable by the qubes group. And the rest of the policies are in
/etc/qubes-rpc/policy, and they're all writable by the qubes group
(except for qubes.SyncAppMenus, which is the root group, and for some
reason qubes.ClipboardPaste is executable).

Still though, for some reason it's not saving my "Yes to All" setting.

--
Micah Lee

[Joanna Rutkowska]

On 05/06/14 22:28, Micah Lee wrote:
> On 05/06/14 14:09, Marek Marczykowski-Górecki wrote:
>> On 06.05.2014 19:59, Micah Lee wrote:
>>>> Also, I'm not able to send emails that are just signed by not encrypted.
>>>> When I try, I get this error in an OpenPGP Alert window:
>>>>
>>>> Error - encryption command failed
>>
>> This last issue is one probably already fixed in upcoming 2.0.3 package (there
>> was a bug which cut off the last char of cmdline...). This can also be a
>> reason for failed encryption.
>
> Oh great. When will it be in the unstable repo so I can upgrade? I can't
> wait for this to work better.
>

Just uploaded to current-testing :)

j.

[Marek Marczykowski-Górecki]

On 06.05.2014 22:28, Micah Lee wrote:
> I have both /etc/qubes-rpc and /etc/qubes_rpc.
>
> In /etc/qubes_rpc/policy there's qubes.Gpg and qubes.PdfConvert, both
> writable by the qubes group. And the rest of the policies are in
> /etc/qubes-rpc/policy, and they're all writable by the qubes group
> (except for qubes.SyncAppMenus, which is the root group, and for some
> reason qubes.ClipboardPaste is executable).
>
> Still though, for some reason it's not saving my "Yes to All" setting.

Ah, this "qubes_rpc" vs "qubes-rpc" can be the reason. This is also fixed in
2.0.3.

[Micah Lee]

I just updated and it's already working much better. The gpg for given
domain timeout is working now, and I'm also able to successfully verify
signatures when I look at signed emails.

However it still gives the same "Error - encryption command failed" when
sending an email that's signed but not encrypted.

And "Yes to All" still isn't working, but it seems like that's a simple fix.

--
Micah Lee

[Marek Marczykowski-Górecki]

Do you have your logging script still in place? If yes, can you send command
line used there?

> And "Yes to All" still isn't working, but it seems like that's a simple fix.

This can be fixed by updated dom0 package (qubes-gpg-split-dom0).

[Micah Lee]

On 05/06/14 17:38, Marek Marczykowski-Górecki wrote:
> On 06.05.2014 23:13, Micah Lee wrote:
>> On 05/06/14 16:46, Joanna Rutkowska wrote:
>>> On 05/06/14 22:28, Micah Lee wrote:
>>>> On 05/06/14 14:09, Marek Marczykowski-Górecki wrote:
>>>>> On 06.05.2014 19:59, Micah Lee wrote:
>>>>>>> Also, I'm not able to send emails that are just signed by not encrypted.
>>>>>>> When I try, I get this error in an OpenPGP Alert window:
>>>>>>>
>>>>>>> Error - encryption command failed
>>>>>
>>>>> This last issue is one probably already fixed in upcoming 2.0.3 package (there
>>>>> was a bug which cut off the last char of cmdline...). This can also be a
>>>>> reason for failed encryption.
>>>>
>>>> Oh great. When will it be in the unstable repo so I can upgrade? I can't
>>>> wait for this to work better.
>>>>
>>>
>>> Just uploaded to current-testing :)
>>
>> I just updated and it's already working much better. The gpg for given
>> domain timeout is working now, and I'm also able to successfully verify
>> signatures when I look at signed emails.
>>
>> However it still gives the same "Error - encryption command failed" when
>> sending an email that's signed but not encrypted.
>
> Do you have your logging script still in place? If yes, can you send command
> line used there?

I just added logging back in place to test it.

When I try sending a signed (but not encrypted) email, it runs this:

/bin/qubes-gpg-client --charset utf-8 --display-charset utf-8
--use-agent --no-tty --batch --no-tty --status-fd 2 -t --clearsign -u
0x99999697 --use-agent
/bin/qubes-gpg-client --charset utf-8 --display-charset utf-8
--use-agent --no-tty --batch --no-tty --status-fd 2 --digest-algo sha512
-s -b -a -t -u 0x99999697 --use-agent

I believe the first command works fine. It unlocked my key on gpgvm. I
think the second command is where it errored.

>> And "Yes to All" still isn't working, but it seems like that's a simple fix.
>
> This can be fixed by updated dom0 package (qubes-gpg-split-dom0).

I think this might be an unrelated problem I'm having. But my Qubes VM
Manager consistently has a little updates available icon next to it,
when when I right-click and choose Update VM it sometimes says there's
no updates available, or sometimes it says firewallvm is downloading
updates, but it always ends up with the icon still there saying I have
updates available.

Is there a way to update dom0 from the command line?

--
Micah Lee

[Marek Marczykowski-Górecki]

Looks like --digest-algo isn't handled properly.

>>> And "Yes to All" still isn't working, but it seems like that's a simple fix.
>>
>> This can be fixed by updated dom0 package (qubes-gpg-split-dom0).
>
> I think this might be an unrelated problem I'm having. But my Qubes VM
> Manager consistently has a little updates available icon next to it,
> when when I right-click and choose Update VM it sometimes says there's
> no updates available, or sometimes it says firewallvm is downloading
> updates, but it always ends up with the icon still there saying I have
> updates available.

Looks like this issue:
http://wiki.qubes-os.org/trac/ticket/824

> Is there a way to update dom0 from the command line?

Yes, qubes-dom0-update tool.

[Marek Marczykowski-Górecki]

Joanna, what do you think about it? This can be some privacy issue, but
gpg-split isn't designed for privacy... --list-keys is allowed anyway.

[Marek Marczykowski-Górecki]

Fixed in 2.0.4 (just uploaded to unstable repo). Also fixed asking for key
access (it was working, but the first "allow for 300s"...).

And indeed thunderbird clears QUBES_GPG_DOMAIN environment variable. So either
some wrapper is needed (the current solution), or alternative way to provide
the domain name (config file?).

[Micah Lee]

On 05/06/14 21:11, Marek Marczykowski-Górecki wrote:
> Fixed in 2.0.4 (just uploaded to unstable repo). Also fixed asking for key
> access (it was working, but the first "allow for 300s"...).

Yay! I can sign emails again when I'm not encrypting.

> And indeed thunderbird clears QUBES_GPG_DOMAIN environment variable. So either
> some wrapper is needed (the current solution), or alternative way to provide
> the domain name (config file?).

The wrapper is working fine for me, though a config file could be cleaner.

Also, I often see emails that are signed, but I don't have the public
key in my keyring. In enigmail I can normally click Details > Import Key
and it will download the key a key server based on keyid.

This, of course, doesn't work. Instead I can click Details > Import Key
and it will show me the keyid. I copy the keyid and run this recv_key
script I wrote in a terminal.

[user@email ~]$ ./recv_key CAD7D72C
gpg: requesting key CAD7D72C from hkp server keys.gnupg.net
gpg: key CAD7D72C: "Marek Marczykowski (marmarek)
<marm...@invisiblethingslab.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
sent 1/2 KB

Here's the script:

[user@email ~]$ cat recv_key
#!/bin/bash
/bin/gpg --recv-keys $1
/bin/gpg --export $1 > /tmp/$1.asc
qvm-copy-to-vm gpgvm /tmp/$1.asc
qvm-run gpgvm gpg --import /home/user/QubesIncoming/email/$1.asc

(And I know, keyids are weak and terrible and you should use full
fingerprints instead. And also, public keys are untrusted input, so it's
dangerous to copy them to my secure gpgvm to import... but there isn't
really much of a choice. And this is way better than just using
thunderbird, enigmail, and gpg with a normal monolothic kernel OS.)

--
Micah Lee

[Joanna Rutkowska]

So, actually there is a choice -- to use the GPG v2 split architecture
which would not require one to copy the (untrusted) public keys to the
trusted GPG VM, see the discussion in this ticket:

http://wiki.qubes-os.org/trac/ticket/474

The ticket is waiting for somebody to implement it...

joanna.

[Joanna Rutkowska]

I assume you left your qrexec policy to always *ask* to allow your email
domain to do qubes.VMShell (which is used to implement qvm-run) on your
gpgvm, don't you? Otherwise the email VM would be able to do whatever it
want via qvm-run, such as e.g. get your secret keys!

In fact it is even a security risk to use the "ask" policy in this case,
because even if you manually allow qubes.VMShell you don't really know
what command the requesting VM will actually send to the target VM for
execution. Sure, you expect that this will be the "gpg --import" because
you just run your script, but if the email VM was compromised, the
malware there might just wait for your to do that, and quickly throw in
some other commands to execure, perhaps in addition to your original
commands, in order to not alert you that something doesn't work.

In other words: allowing qubes.VMShell is extremely dangerous and makes
sense only in case the target VM is considered less trusted than the
source VM. I'm thinking how we should prevent such user mistakes in the
future? Perhaps we should remove qubes.VMShell?

The proper way for the above would be to write your own trivial qrexcec
service, say qubes.SplitGPGImportKeys, which would be handled by a
trivial program on your target VM (it would be just expecting an .asc
file send over stdin).

joanna.

[Marek Marczykowski-Górecki]

I think gpg --import can be called directly (i.e. "gpg --import" is the
content of /etc/qubes-rpc/qubes.SplitGPGImportKeys).

[Joanna Rutkowska]

As a quick solution I would suggest that we change the default policy
file for qubes.VMShell service:

http://git.qubes-os.org/?p=joanna/core-admin.git;a=blob;f=qubes-rpc-policy/qubes.VMShell.policy;h=412173374d423893575a3abc8d25fc6f1a1f7c80;hb=HEAD

... to read:

$anyvm $dispvm allow
$anyvm $anyvm deny

Now if a user uses qvm-run from a VM to another VM there will be no
prompt to click yes, it will be silently discarded. Only if the user is
really determined, the user would then go and edit this policy file
manually adding exception.

In addition we should add a big scary warning in this very qubes.VMShell
policy file warning above the above-discussed danger.

BTW, in case you're wondering if the "$anyvm $dispvm allow" is not a
problem, such as in case whether it allows other AppVMs to access an
already running dispVM (which is viewing my secret confidential work
PDF) -- well it is not, as the $dispvm keyword works only for the dispvm
that is created for the very service innovation (and yes, I just double
checked it :)

joanna.

[Joanna Rutkowska]

Ah, yes, which makes it uber-trivial then :)

So, it's interesting to me why people don't want to write their own
qrexec services, and so often tend to (abuse) qvm-run?

j.

[Joanna Rutkowska]

We can easily provide our wrapper as part of qubes-split-gpg package.
e.g.: /usr/bin/qubes-gpg-client-wrapper.sh :)

Alternatively, we could expect the domain name to be always the argv[1]
of our qubes-gpg-client.

j.

[Marek Marczykowski-Górecki]

I like this idea :)

> In addition we should add a big scary warning in this very qubes.VMShell
> policy file warning above the above-discussed danger.
>
> BTW, in case you're wondering if the "$anyvm $dispvm allow" is not a
> problem, such as in case whether it allows other AppVMs to access an
> already running dispVM (which is viewing my secret confidential work
> PDF) -- well it is not, as the $dispvm keyword works only for the dispvm
> that is created for the very service innovation (and yes, I just double
> checked it :)
>
> joanna.
>

[Marek Marczykowski-Górecki]

And that wrapper can read config file and set QUBES_GPG_DOMAIN.

> Alternatively, we could expect the domain name to be always the argv[1]
> of our qubes-gpg-client.

This doesn't work with thunderbird - it expect single binary path.

[Joanna Rutkowska]

To ja komitne, ze stosownym komentarzem, tak?

[Joanna Rutkowska]

I see "Additional parameters for GnuPG" in the Advanced Tab of Enigmail...

[Marek Marczykowski-Górecki]

There are placed in the middle of cmdline... Really, just before --batch in
above cited command.

[Joanna Rutkowska]

Ok, so the config file, but we should keep it in /rw/config.

j.

[Marek Marczykowski-Górecki]

Of course.

[Joanna Rutkowska]

I was about to say that this might cause some privacy leaks if somebody
used more than one client vm with one gpg vm, but then I realized that,
as our policy control is not granular enough to allow/deny specific key
usages (only full access to keyring vs no access at all), then it would
not be a good scenario anyway.

So, yes, I think no problem.

j.

[Andrew B]

I support this idea, but I disagree with your last statement. This policy (and obviously the current policy) poses an isolation risk: if I have either
1) A VM which has no NetVM (e.g. 'vault'), or
2) A VM with restrictive firewall rules
the above policy allows Qubes-targeted attacks to silently and simply escape the sandbox and use a DispVM to communicate with the outside world. I know Qubes firewall rules are not supposed to provide security guarantees, but the first scenario is still valid.

Maybe we can enforce a policy that when a VM runs the qubes.VMShell service on a DispVM, the DispVM gets the same NetVM (or none) as the caller, and the firewall rules of the caller are also applied to the instantiated DispVM (is this already the case? I don't think so).

Andrew

[Marek Marczykowski-Górecki]

The firewall rules are already inherited by new DispVM from calling VM. This
is the reason why when setting firewall to 'none' firewall is also set to
'block all'.
The NetVM itself isn't inherited, so this can be used to evade TorVM... But
one can simply modify the policy to deny dispvm access (or change to "ask")
from "anonvm". Perhaps we should add it to torvm documentation.

[Micah Lee]

Another thing that could be helpful to people using a gpgvm. If you ever
do software development and need to create a signed git tag (git -s
tagname), it looks like git calls gpg directly and ignores any alias you
set, and gives an error like this:

[user@dev torbrowser-launcher]$ git tag -s v0.0.9
gpg: cannot open tty `/dev/tty': No such device or address
error: gpg failed to sign the data
error: unable to sign the tag
The tag message has been left in .git/TAG_EDITMSG


To deal with this, you need to create another qubes-gpg-client wrapper
script that specifically uses --no-tty, like this:

[user@dev bin]$ cat qubes-gpg-client-wrapper
#!/bin/bash
export QUBES_GPG_DOMAIN="gpgvm"
exec /bin/qubes-gpg-client --no-tty --use-agent "$@"


And then make /bin/gpg a symblink to it, e.g.:

[user@dev ~]$ cd /bin
[user@dev bin]$ sudo mv gpg gpg.bak
[user@dev bin]$ sudo ln /home/user/bin/qubes-gpg-client-wrapper gpg


Now it works like expected. Of course, the next time there's a gnupg
update you'll have to regenerate the symlink.

--
Micah Lee

[Marek Marczykowski-Górecki]

Documentation says you can set gpg.program in git config, but I haven't tested
it. Perhaps even adding those gpg options in that setting will work?

[Micah Lee]

FYI, https://i.imgur.com/XFQyhzk.png is what happens when you you're
using a gpgvm and you leave your computer for awhile with
thunderbird/enigmail open.

--
Micah Lee

[Joanna Rutkowska]

Hmmm, I don't see this effect on my system. It seems like your
TB/Enigmail is attempting to automatically process each incoming message?

Nevertheless, I admit this UI could be improved ;) E.g. it should not
ask for new confirmation if the prior prompt still unanswered. Care to
send patches?

Oh, and BTW, while at it, note that we've added a ground-braking new
feature to qubes-gpg-server which is to show a tray notification every
time the keyring gets accessed from other VM :)

Unfortunately the default tray notification server that we happen to
have in our VMs simply sucks and e.g. if there are more than 20
unapproved notifications displayed it no longer pops up new
notifications. Anyone care to tweak this somehow?

Thanks,
joanna.

[Axon]

Marek Marczykowski-Górecki:

Similar considerations also apply to qubes.OpenInVM. The default is:

$anyvm $dispvm allow
$anyvm $anyvm ask

Suppose I download a (possibly malicious) file in my AnonVM which, if
opened, phones home and exposes my real external IP address. Then
suppose I right click on the file because I want to do something
innocuous with it, but I accidentally click "Open in Disposable VM."
(This exact misclick has actually happened to me many times since I
started using Qubes.) The file then opens in a (firewallvm-connected)
DispVM and successfully phones home, exposing me.

For this reason, I've personally opted to comment out the first line.
Now, whenever I try to open a file in a DispVM, I get a prompt asking
whether I want to proceed. However, the prompt names only the
originating VM and the destination VM. It does not specify the filename,
so I have no idea whether I'm saying "yes" to the file I actually mean
to open (as opposed to some hidden, malicious file which had the
open-in-dispvm action triggered on it a millisecond earlier, or something).

[Axon]

Axon:

On second thought, it's a pain to have to confirm every single time (and
it will be an even bigger pain once "Open link in DispVM" becomes an
option). So, instead, how about an "is an AnonVM" flag? And every VM
with the "AnonVM" flag will by default have "Open X in DispVM" disabled.

[Axon]

Axon:

FYI, there doesn't seem to be any benefit to AnonVMs having permissive
firewall rules. My AnonVMs all have "Deny all" and all of the "Allow X"
boxes unchecked, yet function perfectly well. The only problem is that
this needs to be set manually (AFAICT).

[Marek Marczykowski-Górecki]

You can always modify the policy yourself, assume it is a part of creating
AnonVM - just additional configuration step after setting its netvm to TorVM.
Care to update wiki page?

[Axon]

Marek Marczykowski-Górecki:

Fair enough. Wiki page updated. :)