[gentoo-user] What do you think about pam-gnupg?

[efeizbudak]

Hi all,

I let mutt-wizard set a cron job which takes my password out of pass,
logs into the email server and fetches my mail every 5 minutes. With
this I have to unlock my key as frequently as the amount in
gpg-agent.conf's default-cache-ttl setting. pam-gnupg has been suggested
as a remedy to this problem but the disclaimer on its page about
dangerous bugs make me hesitant to use it. What do you think about the
security of it? It's only 500 SLOC but I don't trust myself with
reviewing the security of it.

[Matt Connell]

Post by efeizbudak
I let mutt-wizard set a cron job which takes my password out of pass,
logs into the email server and fetches my mail every 5 minutes. With
this I have to unlock my key as frequently as the amount in
gpg-agent.conf's default-cache-ttl setting.

I don't have any thoughts on the pam module, but I make use of some
scripts that rely on pass as well. For my use case I just raised the
TTL setting of gpg-agent to match an eight hour work day or eight hour
evening period and ran with it. Feels fairly natural to "log in" to
the agent once a day at the first use.

Disclaimer: I work from home and lock my computers when I'm away from
them.

[Grant Taylor]

Post by efeizbudak
Hi all,

Hi,

Post by efeizbudak
I let mutt-wizard set a cron job which takes my password out
of pass, logs into the email server and fetches my mail every
5 minutes.

Can you re-architect this as a (pseudo) daemon so that you unlock it
once (or at least a LOT less often) and it stores the necessary
information in memory for subsequent re-use?

Post by efeizbudak
With this I have to unlock my key as frequently as the amount in
gpg-agent.conf's default-cache-ttl setting.

:-/

Post by efeizbudak
pam-gnupg has been suggested as a remedy to this problem but the
disclaimer on its page about dangerous bugs make me hesitant to use
it. What do you think about the security of it? It's only 500 SLOC
but I don't trust myself with reviewing the security of it.

I don't relish the idea of giving something the keys to the kingdom.

Could you re-configure things so that (a copy of) the requisite password
is accessible via a different set of GPG credentials specific to the
process that you're running? Then you could probably have just that set
of GPG credentials unprotected so that the script could use them as it
is today.

If neither of these options were possible I'd look into something like a
TPM and / or Yubikey wherein I could offload some of the GPG to it so
that the decryption key is physically tied to the source computer /and/
*where* *it* *can't* *be* *copied*.

I might also look into other authentication methods, e.g. TLS client
certificate, so that the script can do what it needs to without needing
to bother with GPG.

[Matt Connell]

Post by Grant Taylor
Can you re-architect this as a (pseudo) daemon so that you unlock it
once (or at least a LOT less often) and it stores the necessary
information in memory for subsequent re-use?

You just described gpg-agent, the core of what Efe (OP) is meddling
with :)

Post by Grant Taylor
Could you re-configure things so that (a copy of) the requisite password
is accessible via a different set of GPG credentials specific to the
process that you're running?  Then you could probably have just that set
of GPG credentials unprotected so that the script could use them as it
is today.
If neither of these options were possible I'd look into something like a
TPM and / or Yubikey wherein I could offload some of the GPG to it so
that the decryption key is physically tied to the source computer /and/
*where* *it* *can't* *be* *copied*.

Since pass, the utility that OP is using in their script, is built
around GPG, of course there have been some spinoffs, using other
encryption methods. Personally setting the gpg-agent timeout higher
and having good physical security works for my use case, but everyone
has a different situation. If I worked in an office still, I think I
would have a physical GPG-based key solution, though I will admit I'm
not read up on which ones are the tops right now.

Efe, it may be useful to review the pass mailing list archives[1] for
some other ideas. I don't think you're trying to solve a snowflake
problem here, but pam tie-ins doesn't feel quite right for a solution
either.

1: https://lists.zx2c4.com/pipermail/password-store/

[Grant Taylor]

Post by Matt Connell
You just described gpg-agent, the core of what Efe (OP) is meddling
with :)

No, I didn't.

I was referring to having the OP's utility read the password and
interact with GPG /once/ at startup and then the utility run for a much
longer time retaining the decrypted password in it's memory.

The difference may seem subtle, but it is very important to understand.

[efeizbudak]

Post by Matt Connell
I don't have any thoughts on the pam module, but I make use of some
scripts that rely on pass as well. For my use case I just raised the
TTL setting of gpg-agent to match an eight hour work day or eight hour
evening period and ran with it. Feels fairly natural to "log in" to
the agent once a day at the first use.

Doesn't this sort of defeat the purpose of using pass? I mean if it's
always decryptable then is it really useful to have it encrypted in the
first place (assuming you have full disk encryption set up)? I may be
missing something crucial here so please let me know.

Post by Matt Connell
Can you re-architect this as a (pseudo) daemon so that you unlock it
once (or at least a LOT less often) and it stores the necessary
information in memory for subsequent re-use?

This seems like the lesser of all evils to me. As I understand, you're
suggesting that I lend the email password to the daemon at start and
only have that password stored in memory instead of my actual gpg
password, is that correct?

Post by Matt Connell
Could you re-configure things so that (a copy of) the requisite password
is accessible via a different set of GPG credentials specific to the
process that you're running? Then you could probably have just that set
of GPG credentials unprotected so that the script could use them as it
is today.

Again, I may be missing something here, but does having your GPG
credentials unprotected offer any real protection?

Post by Matt Connell
If neither of these options were possible I'd look into something like a
TPM and / or Yubikey wherein I could offload some of the GPG to it so
that the decryption key is physically tied to the source computer /and/
*where* *it* *can't* *be* *copied*.

I guess this is where I'll eventually be heading towards.

By the way, thanks to both of you for your thoughts!

[Grant Taylor]

Post by efeizbudak
Doesn't this sort of defeat the purpose of using pass? I mean if it's
always decryptable then is it really useful to have it encrypted in the
first place (assuming you have full disk encryption set up)? I may be
missing something crucial here so please let me know.

There is value in not having a password in clear text on a file system.

It really depends on what your trying to protect from / against.

Post by efeizbudak
This seems like the lesser of all evils to me. As I understand, you're
suggesting that I lend the email password to the daemon at start and
only have that password stored in memory instead of my actual gpg
password, is that correct?

I think we're talking about the same thing.

Post by efeizbudak
Again, I may be missing something here, but does having your GPG
credentials unprotected offer any real protection?

See my response to your comment / question to Matt.

Post by efeizbudak
I guess this is where I'll eventually be heading towards.

I'm personally looking forward to being able to use TPMv2 to protect
keys for services running on the system. It requires said services to
support the TPM.

Post by efeizbudak
By the way, thanks to both of you for your thoughts!

:-)

[Matt Connell]

Post by efeizbudak
Doesn't this sort of defeat the purpose of using pass? I mean if it's
always decryptable then is it really useful to have it encrypted in
the first place (assuming you have full disk encryption set up)?

Yes and no.

Yes in the sense that a rouge piece of software or a bad human actor
could execute `pass $path` and acquire the given secrets, so long as
the gpg-agent is holding the provided password.

No in the sense of that the file itself (remember pass stores
individual files for each secret) is still encrypted at rest. That is
to say, unless someone or some software is specifically looking for
gpg-encrypted files and knows how to use gpg or pass, they cannot
access the data.

The original point I was trying to make (in the previous message) is
that usability and security are always going to compromise one another,
and it is up to each of us to decide where the right balance lies.
Since I don't consider local malware a legitimate threat, my concerns
are limited to bad human actors. Working from home, and locking my
computers when leaving them, gpg-agent being unlocked for eight hours
after the start of the work day is sufficient security.

People who use gnome-keyring (myself included!) probably don't think
twice about the fact that the keyring gets unlocked *once* and stays
unlocked until the user's session ends. Heck some of my sessions can
last *months* on some machines. Sure, most of us have rigged it up to
use a pam library, but the the situations parallel. The access agent
is still "unlocked" for long periods of time, while the data on disk
remains encrypted at rest.