On Thu, 2005-06-09 at 13:54 +0200, Magnus Hagander wrote:
> > 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.
> 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).
2) there's not need for the intruder to scale to administrator powers.
If they break the 'postgres' account, they read the key. Even if they
break the server at SQL level, i.e. they gain superuser for the
database, they may be able to read it with a COPY SQL command, since
it's likely the key is accessible to the server (I'm not claiming the
latter is feasible - just in theory that's all they need).
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.
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.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
