--- 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. > > 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. > Now THAT puzzles me a lot. I can imagine it be > restored in plain. I can > imagine it be restored encrypted. I have no way to > justify the file > contents being lost only because of restoring it on > FAT. If the encrypted file can be restored in plain to FAT, it's useless. Anyone can backup and then resore it to decrypt the file. And the file is not lost, you can still restore it from the backup. It's not so hard to find an NTFS partition, Postgres requires NTFS to run. > > Anyway, that's not the point here. > > The point is: on Windows, if someone breaks in your > 'postgres' account, > he can read the key. If someone breaks in your > 'administrator' account, > he can read the key. But other users cannot read it. > > This level of protection is exactly the same > provided by the 400 > permissions above under Unix. If someone breaks in > the 'postgres' > account, he can read the key. If someone breaks in > the 'root' account, > he can read the key. But other users cannot read it. > > I fail to see any difference in the above scenarios. > 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. > Encrypting the key in the .pem file (as supported by > openssl) is > completely different! No one, ever, can access it > w/o knowing the > password. That's why it takes the operator to type > the password in. > Also backups are safe. And just as useful as the > file itself, they can > be restored everywhere. If someone forgets the > password, the contents > are lost, but that's true for the file itself. The > backup is just what > you expect to be, a copy. You restore it, and get a > _working_ copy for > the file, on every filesystem. The .pem key can be > sent by email even, > as is (since it's base64 encoded). > 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. > 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. > 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. > .TM. > -- > ____/ ____/ / > / / / Marco > Colombo > ___/ ___ / / Technical > Manager > / / / ESI s.r.l. > _____/ _____/ _/ > Colombo@xxxxxx > > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > cheers, Changyu __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@xxxxxxxxxxxxxx)
