Re: Permissions - Mailing list pgsql-novice

From Andre Labuschagne
Subject Re: Permissions
Date
Msg-id CE8C025A-43A4-457F-8DE2-4FD559180DE5@eduadmin.com
Whole thread Raw
In response to Re: Permissions  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-novice

On 20 Sep 2016, at 23:30, David G. Johnston <david.g.johnston@gmail.com> wrote:

On Tue, Sep 20, 2016 at 2:17 PM, Andre Labuschagne <technical@eduadmin.com> wrote:

Hi David

Our usage of the terms is the exact opposite.

I am simply referring to the database being taken else mounted and accused.  We can refer to that as at rest.  If we restrict access when it has “left” the initial PG server and mounted onto another PG server then we have a solution.   But your reference to the little tool that enables trust seems to blow all security out of the water.  It is troublesome.


​There are many external tools that will encrypt files.  You can also setup a filesystem that has encryption features.​  You don't necessarily need the full cooperation of PostgreSQL to make things meet your definition/trade-off of secure.

IMHO, The "little tool that enables trust" really isn't a problem by itself (and its not really a tool...) but rather has a slight impact of the potential risk surface and learning curve.  It probably shouldn't be used in production but can come in handy in other setups.  You've already lost once some gets a hold of unencrytped data files - a problem that can be readily solved outside of PostgreSQL - that its a bit easier to spin up the database and access the database is just opening the barn door a bit further.

There are many others on these lists, and in the community, more knowledgeable in security than I.  It can be made considerably more secure than it comes "out of the box".

David J.


Hi David

In the end to make this project practical we basically need to be able to create databases at HQ [and apps to go with them of course] and get the sites to mount the databases agains a PG server but not be able to tamper with the database in any form whatsoever - backing up [we will do that programmatically with pgDump for example] or accessing or whatever.  That is what we are wanting to do.  If this can be done it will of course cover theft as well as the same behaviour will apply to any other server.

The trust tool that you mentioned - is this universally available to any hacker or theft of the database?  So a rogue employee can get their hands not?  No special skill required?

Cheers
Andre

pgsql-novice by date:

Previous
From: Andre Labuschagne
Date:
Subject: Re: Permissions
Next
From: Alan Hodgson
Date:
Subject: Re: Permissions