Mailing List Archive

What do you think about pam-gnupg?
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.

--
All the best,
Efe

The funny quote of this email is trivial and left as an exercise.
Re: What do you think about pam-gnupg? [ In reply to ]
On Wed, 2023-03-01 at 09:10 -0500, efeizbudak wrote:
> 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.
Re: What do you think about pam-gnupg? [ In reply to ]
On 3/1/23 7:10 AM, efeizbudak wrote:
> Hi all,

Hi,

> 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?

> 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.

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.



--
Grant. . . .
unix || die
Re: What do you think about pam-gnupg? [ In reply to ]
On Wed, 2023-03-01 at 15:38 -0700, Grant Taylor wrote:
> 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 :)

> 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/
Re: What do you think about pam-gnupg? [ In reply to ]
On 3/2/23 6:48 AM, Matt Connell wrote:
> 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.



--
Grant. . . .
unix || die
Re: What do you think about pam-gnupg? [ In reply to ]
Matt:
> 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.

Grant:
> 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?

> 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?

> 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!

--
All the best,
Efe

The funny quote of this email is trivial and left as an exercise.
Re: What do you think about pam-gnupg? [ In reply to ]
On 3/2/23 9:53 PM, efeizbudak wrote:
> 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.

> Grant:
>
> 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.

> 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.

> 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.

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

:-)



--
Grant. . . .
unix || die
Re: What do you think about pam-gnupg? [ In reply to ]
On Thu, 2023-03-02 at 23:53 -0500, efeizbudak wrote:
> > 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.