Re: Have an encrypted pgpass file - Mailing list pgsql-hackers

On Wed, Aug  1, 2018 at 05:33:39PM +0200, Marco van Eck wrote:
> After explaining the patch to a college we identified potentially execution of
> another user when it is defined in as a command parameter. To protect agains it
> I've removed the possibility to pass the 'passcommand'. With the result libpq
> only allows the PGPASSCOMMAND environment variable, which can only be defined
> by the executing user, and will be executed by the same user. It only reduces
> the need of unencrypted password's in a file. 
> 
> I think this solution is secure enough, shall we solve this feature-request?

[Toshi and Nico added as CC's]

I think we need to step back and understand where we are going with our
various encryption options.  We have this feature under consideration,
and we have a proposal for data-at-rest encryption, which encrypts
writes to the file system:

    https://www.postgresql.org/message-id/CA%2BCSw_tb3bk5i7if6inZFc3yyf%2B9HEVNTy51QFBoeUk7UE_V%3Dw%40mail.gmail.com

So, until now, we have only supported encryption at the "optimal" level,
e.g. encrypted file system which encrypts the storage.  We have relied
on file permissions to protect access to the mounted file system, and
have a similar approach to securing .pgpass.  So, the question is
whether we continue to offer only encryption at the "optimal" level, or
whether we allow encryption at other levels.

There are two reasons to support non-optimal encryption levels.  First,
there is the issue that different threat models require different
encryption levels for protection.  For example, someone might have the
ability to _read_ a directory, but not the ability to modify it and
therefore attack it by grabbing passwords as they are typed.  An
encrypted .pgpass would be secure from that attack, but a .pgpass stored
on an encrypted file system would not.

Second, there should always be some kind of unlocking action, either
with a password, a hardware encryption device, or connection to a key
server.  Sometimes this unlocking action only makes sense at a certain
level, e.g. a personal Yubikey works for .pgpass but might be odd for
file system encryption.

I sympathize with concerns that the encryption key might be stored
unencrypted, or stored with the key that decrypts the encryption key. 
However, I don't think we can assume that there are no valid uses for
encryption at non-optimal levels, and that they would only be used in
insecure ways.

As a practical example, this presentation:

    http://momjian.us/main/writings/crypto_hw_use.pdf

shows how you might use a Yubikey to encrypt .pgpass.  The private key
can't be copied out of the Yubikey, but the private key wouldn't be used
to encrypt .pgpass --- instead a key would be encrypted using the
Yubikey's private key.  An attacker wouldn't need to read the Yubikey
private key but read the .pgpass password once it is decrypted.  That
could be done by modifying the gpg binary, the psql binary, or the
gpg-agent script, but those all require modification of something, with
proper permissions and possible detection.  I don't know how valuable
that would be to the average user, but I am sure it is useful for some
users.

I think with proper documentation and warnings, we could make these
non-optimal encryption levels useful for the users who have threat
models where they are useful, and hopefully minimize their misuse.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +