On Thu, 2005-06-09 at 05:21 -0700, Changyu Dong wrote:
> --- Marco Colombo <pgsql@xxxxxxxxxx> wrote:
>
> > As long as the 'postgres' user has access to it w/o
> > typing any password,
> > that's only a detail. Unless someone physically
> > steals your disk, the
> > fact it's stored encrypted is irrelevant. The only
> > thing that matters is
> > who can access it, and how.
> >
> > That's how the permission bits work in Unix. No need
> > to encrypt the
> > file, we know permission bits actually work as
> > expected under Unix. In
> > this case encryption adds no extra level of security
> > on a running
> > system.
> >
> > I fail to see the difference. On Windows, the
> > 'postgres' user can read
> > it without password. 'Administrator' has access to
> > it, too.
> >
> > On Unix, with 400 permissions, the 'postgres' user
> > can read it without
> > password. 'root' has access to it, too.
> >
> Then how about resore it from a backup to another
> system? In this way the permission is bypassed but EFS
> still works.
Either the Windows backup contains the private key of the user or not.
If not, the backup is incomplete and useless (to get the file contents).
You may get other files from it, but that's not the point. You may just
not include the key file in _that_ backup.
If you have two backups, one "normal" and another "safe", just put the
keyfile on the safe one, along with the other private keys. You can do
the same under Unix of course.
If your single backup contains the user private key, EFS is bypassed as
well.
This is going offtopic. The EFS approach is no different from any
encrypted filesystem, nothing new under the sun. It shares the weakness
of any system that lets you access the data at runtime w/o password.
> > Then the backup is useless. If the secret key of the
> > user 'postgres' is
> > lost (and it can be, since it is stored elsewhere, I
> > think buried
> > somewhere where 'Administrator' can find it, maybe
> > in user profile),
> > you'll never recover then content of the file.
> >
> Right, but the user's private key can be exported into
> a password protected pem file.
Save the server key in the same way then. Put the server key and the
user key together.
[...]
> If an intruder can break the postgres or root account,
> he can read everything, as have been discussed, not
> only the key but also the data file. So in this
> situation, it's useless to protect the key only.
Yes, it has been discussed: the purpose of the key is not protecting the
data, but protecting your identity. If the key is compromised, they can
impersonate you. Generally, this is much bigger a damage. They can
create fake data, _signed by you_.
[...]
> Yes, the .pem file can be kept for distribution and
> backup, but the working copy has to be plain.
>
> > The daemon should ask for the password only once, we
> > agree on that.
> >
> Yes, that's the ultimate solution. So we can use
> encrypted key without any outside mechanism.
We agree on that. That's the _only_ solution if you want that kind of
security.
> > Storing the key encrypted (in the openssl sense)
> > doesn't help much
> > against root, if he's able to trick the operator
> > into typing the
> > password again. If you're able to avoid it, that is
> > you're in a highly
> > secure environment with operators trained _not_ to
> > type the password in
> > "just to have the server restarted", .pem encryption
> > adds a lot to your
> > security.
> >
> I'm not sure, but windows begins to support smart card
> logon, therefore no password will be need and stored.
That changes nothing. Somehow the key as to be given, unencrypted, to
the server. Be it an operator typing a password, or inserting a
smartcard, a patched server can store the key in cleartext anywhere.
You have to teach your operators to think twice before performing
anything that lets the server access the key. With your solution, you're
letting the server access the key automatically.
> > 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.
> >
> At least it make it impossible to restore the plain
> key from backup.
The safety of that backup lies only on its incompleteness.
If you include the user key in the same backup, there's no security.
If you don't include the user key (and thus create an incomplete
backup), it's easier not to include the server key either, and put it in
the same place you put the user key. They are both "private keys".
Including a useless copy of the server key encrypted with the user key
(stored elsewhere) is just a perverse way to gain nothing.
But I agree that sometimes perverse systems make perverse things look
natural. :-)
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
