Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Jun 13, 2017 at 02:38:58PM -0400, Stephen Frost wrote: > > It's good to discuss what the feature would bring and what cases it > > doesn't cover, as well as discussing how it can be designed to make sure > > that later improvements are able to be done without having to change it > > around. I do think it's a good idea for us to consider taking an > > incremental approach where we're adding pieces and building things up as > > we go. I'm concerned that if we try to do too much in the initial > > implementation that we'll end up not having anything. > > > > As it relates to the different attack vectors that this would address, > > it's primairly the same ones which filesystem-level encryption also > > addresses, but it's an improvement when it comes to ease of use. > > Unfortunately, it won't address cases where the OS is compromised. > > OK, so let's go back. You are saying there are no security benefits to > this vs. file system encryption.
I'm not sure that I can see any, myself.. Perhaps I'm wrong there, but it seems unlikely that this would be an improvement over filesystem level encryption in the general sense. I'm not sure that I see it as really worse than filesystem-level encryption either, to be clear. There's a bit of increased information leakage, as Peter mentioned and I agreed with, but it's not a lot and I expect in most cases that information leak would be acceptable. That seems like something which would need to be considered on a case-by-case basis. > The benefit is allowing configuration > in the database rather than the OS? No, the benefit is that the database administrator can configure it and set it up and not have to get an OS-level administrator involved. There may also be other reasons why filesystem-level encryption is difficult to set up or use in a certain environment, but this wouldn't depend on anything OS-related and therefore could be done. > You stated you can transfer > db-level encrypted files between servers, but can't you do that anyway? If the filesystem is encrypted and you wanted to transfer the entire cluster from one system to another, keeping it encrypted with the same key, you'd have to transfer the entire filesystem at a block level. That's not typically very easy to do (ZFS, specifically, has this capability where you can export a filesystem and send it from one machine to another, but I don't know of any other filesystems which do and ZFS isn't always an option..). You could go through a process of re-encrypting the files prior to transferring them, or deciding that simply having the transport mechanism encrypted is sufficient (eg: SSH), but if what you really want to do is keep the existing encryption of the database and transfer it to another system, this allows that pretty easily. For example, you could simply do: cp -a /path/to/PG /mnt/usb and you're done. If you're using filesystem level encryption then you'd have to re-encrypt the data, using something like: tar -cf - /path/to/PG | openssl -key private.key > /mnt/usb/encrypted_cluster.tar And then you would need openssl on the other system to decrypt it. Of course, either way you'd have to provide for a way to get the key from one system to the other. Also, tools like pg_basebackup could be used, with nearly zero changes, I think, to get an encrypted copy of the database for backup purposes, removing the need to work out a way to handle encrypting backups. > Is the problem that you have to encrypt before sending and decrypt on > arrival, if you don't trust the transmission link? Is that used a lot? > Is having the db encrypt every write a reasonable solution to that? There's multiple use-cases here. Making it easier to copy the database is just one of them and it isn't the biggest one. The biggest benefit is that there's cases where filesystem-level encryption isn't really an option or, even if it is, it's not desirable for other reasons. > As far as future features, we don't have to add the all features at this > time, but if someone has a good idea for an API and we can make it work > easily while adding this feature, why wouldn't we do that? Sure, I'm all for specific suggestions about how to improve the API, or just in general recommendations of how to improve the patch. The suggestions which have been made about key management don't really come across to me as specific API-level recommendations but rather "this would also be nice to have" kind of comments, which isn't really the same. Thanks! Stephen
signature.asc
Description: Digital signature
