From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Ants Aasma <ants.aasma@eesti.ee>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: WIP: Data at rest encryption
Date: Tue, 13 Jun 2017 14:38:58 -0400
Message-ID: <20170613183858.GR3151@tamriel.snowman.net> (raw)
In-Reply-To: <20170613182910.GN13873@momjian.us>
References: <20170613150421.GE3151@tamriel.snowman.net>
<20170613160434.GC13873@momjian.us>
<20170613162301.GF3151@tamriel.snowman.net>
<20170613164442.GD13873@momjian.us>
<20170613170132.GH3151@tamriel.snowman.net>
<20170613171356.GG13873@momjian.us>
<20170613172459.GL3151@tamriel.snowman.net>
<20170613174329.GK13873@momjian.us>
<20170613182339.GP3151@tamriel.snowman.net>
<20170613182910.GN13873@momjian.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Bruce,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Jun 13, 2017 at 02:23:39PM -0400, Stephen Frost wrote:
> > I'm not trying to shut down discussion, I'm simply pointing out where
> > this feature will be helpful and where it won't be. If there's a way to
> > make it better and able to address an attack where the OS permission
> > system is bypassed, that'd be great, but I certainly don't know of any
> > way to do that and we don't want to claim that this feature will protect
> > against an attack vector that it won't.
> >
> > If the lack of that means you don't support the feature, that's
> > unfortunate as it seems to imply, to me at least, that we'll never have
> > any kind of encryption because there's no way for it to prevent attacks
> > where the OS permission system is able to be bypassed.
>
> It means if we can't discuss the actual benefits that this feature
> brings, and doesn't bring, and how it will deal with future feature
> additions, then you are right we will never have it.
I apologize for having come across as trying to shut down discussion,
that was not my intent.
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.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, bruce@momjian.us, peter.eisentraut@2ndquadrant.com, ants.aasma@eesti.ee, robertmhaas@gmail.com
Subject: Re: WIP: Data at rest encryption
In-Reply-To: <20170613183858.GR3151@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox