Re: [gentoo-user] What do you think about pam-gnupg?
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.
Re: [gentoo-user] What do you think about pam-gnupg?
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: [gentoo-user] What do you think about pam-gnupg?
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. signature.asc Description: PGP signature
Re: [gentoo-user] What do you think about pam-gnupg?
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: [gentoo-user] What do you think about pam-gnupg?
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: [gentoo-user] What do you think about pam-gnupg?
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: [gentoo-user] What do you think about pam-gnupg?
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.
[gentoo-user] 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. signature.asc Description: PGP signature