Re: vulnerability/SSL

> > > The EFS encryption as you described it adds nothing but a false
> > > sense of security (and the ability to use some more
> buzzwords). The
> > > level of protection is just the same of a Unix file with
> the right
> > > permissions.
> > > The key point here is that both the 'postgres' user and
> > > 'administrator'
> > > have _transparent_ access to the file contents. No
> password required.
> >
> > While most of what you wrote is definitly correct, you missed a few
> > things about EFS.
>
> [...stuff on EFS deleted...]
>
> I agree on that. I'm not saying EFS is a bad idea. I'm only
> considering the server key case. Anyway protecting against a
> malicious superuser is the subject of a chapter on its own.
> There are many ways for a superuser to hijack an user
> account. I'm not a Windows guy, but with a similar setup
> under Unix, I'd do:
>
> su - user -c "cp encrypted_file /tmp/unencrypted"
>
> or anything equivalent. That is, at C level, open(2) the
> file, read(2) it (the system gives me plaintext contents)
> write(2) it to another file.
> The OP said he starts PostgreSQL with 'runas' which I get
> being the Windows relative to 'su' (or 'cron'?). If
> Administrator can run programs as the user, he can read the
> key file. That's the big difference.

Yes, that is correct - runas is similar to su. But in order to do
"runas", you need the service accounts password. Once you are "root" on
a unix system, you can do "su - user" *without* the password. That's a
big difference.
(You can also use the postgres accounts smartcard, if you are using
smartcard logins, but the deal is that you need *something* that is
normally private to the account - even if you are an administrator)


> > So it does offer a bit of extra security. "Just" to protect the key
> > used to set up the SSL sessions, I'm not sure it's worth
> it. Because
> > again, if they hack your admin account, they can get to your files
> > *without* going thruogh getting into the SSL stream.
>
> I think you're missing two points:
>
> 1) the purpose of getting the key is _not_ to be able to
> decrypt the SSL stream (even if that's a nice consequence).
> The worse you can do is _sign_ things with the key, that is,
> impersonate the server, mount man in the middle attacks, and
> so on. Without anyone notice it for a while.
> The whole point of encrypting the key is that a compromised
> key is worse than a compromised system (and way more likely
> to go unnoticed).

Correct, I was looking only at the issue of decrypting the stream.

Well, if you have admin on the server, you can replace the whole
postmaster binary. Which means game over no matter what.


> 2) there's not need for the intruder to scale to administrator powers.
> If they break the 'postgres' account, they read the key.

That is the difference, though. Replacing the binary would require admin
privs, not just postgres privs. (Depending on the installation, of
course, but atl east the default install on win32 will explicitlyi deny
the service acconut permissions to change it's own binaries)

> The problem reported by the OP is a real one, since it
> prevents the usage of an encrypted key. Not a big one, but
> still one. The "solution"
> the OP posted later is not solving the problem at all.

Agreed.


> BTW, even with the key is encrypted (the .pem way), the
> cleartext copy must stay in the server memory space (possibly
> in a locked area). It may be available to root ("debugging"
> the server), the user or the process itself of course, if
> "they" manage to execute arbitrary code. There's not way to
> make it 100% safe.

If they ahve the postgres superuser, and can somehow send/receive files
(COPY for example), they can load a user defined C function, and just
read the server key from there. Sure, it's slightly more complicated
than reading the file, but not really all that much.

I guess we could read in the password ourselves and drop it in our
shared memory segment to pass to subprocesses - though that means they
can get to the password easier as well. Assuming OpenSSL has the APIs
for that, I haven't checked that. I'm unconvinced it makes enough of a
difference to be worthwhile, though.

(BTW, am I correct in reading this as a problem that only appears on
win32, because of the exec nature of the backend, right? Or does it show
up on Unix as well?)

//Magnus