Hello,

Is there not some other alternative to pg_hba.conf?

I have the problem where the system administrators at our company
obviously have access to the whole filesystem, and our database records
needs to be hidden even from them.

With pg_hba.conf that is not possible, as they just change all the conf
lines to "trust" auth and viola they have access to the database without
passwords.

Is there a more secure alternative to this? The perfect scenario being
to deny everyone include "root" access to a database without a password.

regards,
Quintin Beukes

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

I think this was discussed many times on this list, and the main
conclusion was: if you don't trust your DB machine's admin, any security
measure against him will be only illusory. The sysadmin can in any case
access the data, you can just make this harder, you can't prevent that.

So you better get admins who you trust...

On Wed, 2006-02-08 at 13:34, Q Beukes wrote:
> Hello,
>
> Is there not some other alternative to pg_hba.conf?
>
> I have the problem where the system administrators at our company
> obviously have access to the whole filesystem, and our database records
> needs to be hidden even from them.
>
> With pg_hba.conf that is not possible, as they just change all the conf
> lines to "trust" auth and viola they have access to the database without
> passwords.
>
> Is there a more secure alternative to this? The perfect scenario being
> to deny everyone include "root" access to a database without a password.
>
> regards,
> Quintin Beukes
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Wed, Feb 08, 2006 at 02:34:29PM +0200, Q Beukes wrote:
> Is there not some other alternative to pg_hba.conf?
>
> I have the problem where the system administrators at our company
> obviously have access to the whole filesystem, and our database records
> needs to be hidden even from them.
>
> With pg_hba.conf that is not possible, as they just change all the conf
> lines to "trust" auth and viola they have access to the database without
> passwords.

Or they just copy the whole database to another machine and access it
that way. Or copy your backups. Or hack the application accessing the
data (the application has the password in it, right?).

If can stop them doing those things you can stop them altering
pg_hba.conf too so your problem is solved.

> Is there a more secure alternative to this? The perfect scenario being
> to deny everyone include "root" access to a database without a password.

Well, you could change the source to remove struct auth, but then they'd
just compile their own version and overwrite the system one.

Yes, we're looking for alternatives for pg_hba.conf, but what you want
is to dam a river with sheets of paper.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD6ephIB7bNG8LQkwRAgWpAJ9lkztwZmBMEbhz5paGdn cAPqE/sQCfbp3f
CAA6MJdIGE7ca2RCFs5Zfc4=
=dbk/
-----END PGP SIGNATURE-----

> Hello,
>
> Is there not some other alternative to pg_hba.conf?
>
> I have the problem where the system administrators at our company
> obviously have access to the whole filesystem, and our database records
> needs to be hidden even from them.

If they have full access, then they have FULL access.
>
> With pg_hba.conf that is not possible, as they just change all the conf
> lines to "trust" auth and viola they have access to the database without
> passwords.

You are looking for a security that can not exit in your scenario.
>
> Is there a more secure alternative to this? The perfect scenario being
> to deny everyone include "root" access to a database without a password.
>

They only way to secure data is to remove all access to it. If you don't
trust your admins, then you have the wrong admins.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Q Beukes wrote:

>Hello,
>
>Is there not some other alternative to pg_hba.conf?
>
>I have the problem where the system administrators at our company
>obviously have access to the whole filesystem, and our database records
>needs to be hidden even from them.
>
>With pg_hba.conf that is not possible, as they just change all the conf
>lines to "trust" auth and viola they have access to the database without
>passwords.
>
>Is there a more secure alternative to this? The perfect scenario being
>to deny everyone include "root" access to a database without a password.
>
>
>
>

This is an illusion, as plenty of security experts will tell you.
Password auth is a losing game for high security in the first place. So
this comment shows that you haven't thought this out properly.

If you want the data hidden from system administrators, you need to have
the client encrypt it before storing it. Of course, that will have
massive implications for your application.

There are no simple solutions. See here for why:
http://www.acm.org/classics/sep95/

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

>
>
> Q Beukes wrote:
>
>>Hello,
>>
>>Is there not some other alternative to pg_hba.conf?
>>
>>I have the problem where the system administrators at our company
>>obviously have access to the whole filesystem, and our database records
>>needs to be hidden even from them.
>>
>>With pg_hba.conf that is not possible, as they just change all the conf
>>lines to "trust" auth and viola they have access to the database without
>>passwords.
>>
>>Is there a more secure alternative to this? The perfect scenario being
>>to deny everyone include "root" access to a database without a password.
>>
>>
>>
>>
>
> This is an illusion, as plenty of security experts will tell you.
> Password auth is a losing game for high security in the first place. So
> this comment shows that you haven't thought this out properly.
>
> If you want the data hidden from system administrators, you need to have
> the client encrypt it before storing it. Of course, that will have
> massive implications for your application.

And even then, your admins will probably have access to the application
source and, if they want, can get data.

The unpopular reality is that if you must keep something secret, you can't
give access to it to anyone who is not trusted to keep the secret. The
best bet is to have one system that has the "secret" data, managed by
those who are trusted.

It means that the "trusted" people are on the hook for backups and
preventive maintenence, but secrets aren't free.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Well,

I am not looking for 100% security. I know that full access if full access,
and that even if you were to encrypt the system through Postgre the
determined
person WILL always be able to get it out if they have system level access.

All I wanted to do was to prevent the basic SQL/Linux literate user from
accessing
the databases. At the moment it is very easy for them to access the data.

I trust that they wont go as far as overwriting the system with custom
compiled
version, or copying the data and so forth. It just that we would feel
much better
if we knew the data wasn't as open as it is now, with a simple pg
restart it is all
open?

Can this only be done by maybe modifying the source to make pg_hba
fields statically
compiled into the executable?

Martijn van Oosterhout wrote:

>On Wed, Feb 08, 2006 at 02:34:29PM +0200, Q Beukes wrote:
>
>
>>Is there not some other alternative to pg_hba.conf?
>>
>>I have the problem where the system administrators at our company
>>obviously have access to the whole filesystem, and our database records
>>needs to be hidden even from them.
>>
>>With pg_hba.conf that is not possible, as they just change all the conf
>>lines to "trust" auth and viola they have access to the database without
>>passwords.
>>
>>
>
>Or they just copy the whole database to another machine and access it
>that way. Or copy your backups. Or hack the application accessing the
>data (the application has the password in it, right?).
>
>If can stop them doing those things you can stop them altering
>pg_hba.conf too so your problem is solved.
>
>
>
>>Is there a more secure alternative to this? The perfect scenario being
>>to deny everyone include "root" access to a database without a password.
>>
>>
>
>Well, you could change the source to remove struct auth, but then they'd
>just compile their own version and overwrite the system one.
>
>Yes, we're looking for alternatives for pg_hba.conf, but what you want
>is to dam a river with sheets of paper.
>
>Have a nice day,
>
>

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Q Beukes wrote:

>Well,
>
>I am not looking for 100% security. I know that full access if full access,
>and that even if you were to encrypt the system through Postgre the
>determined
>person WILL always be able to get it out if they have system level access.
>
>All I wanted to do was to prevent the basic SQL/Linux literate user from
>accessing
>the databases. At the moment it is very easy for them to access the data.
> mechanism is there for a reason:
>I trust that they wont go as far as overwriting the system with custom
>compiled
>version, or copying the data and so forth. It just that we would feel
>much better
>if we knew the data wasn't as open as it is now, with a simple pg
>restart it is all
>open?
>
>Can this only be done by maybe modifying the source to make pg_hba
>fields statically
>compiled into the executable?
>
>

Of course it would be possible to hardcode the values - it's a SMOC. But
nobody round here is likely to do the work reuired, since nobody
believes it's worth doing, I believe.

This mechanism you object to is there for a reason: if you lock yourself
out of the database you can recover from the error. The solution you are
proposing is therefore a huge footgun.

And your user with basic linux/sql knowledge would still be able to see
data fly by, for example, logging statements, or watching network
traffic. How hard is it to run ethereal, after all, or tail a log file?
There is even a module for ethereal that understands the postgres wire
protocol. You aren't asking for security - you are asking for the
illusion of security, which many would argue is worse than no security
at all.

cheers

andrew



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Q Beukes schrieb:
> Well,
>
> I am not looking for 100% security. I know that full access if full access,
> and that even if you were to encrypt the system through Postgre the
> determined
> person WILL always be able to get it out if they have system level access.
>
> All I wanted to do was to prevent the basic SQL/Linux literate user from
> accessing
> the databases. At the moment it is very easy for them to access the data.
>
> I trust that they wont go as far as overwriting the system with custom
> compiled
> version, or copying the data and so forth. It just that we would feel
> much better
> if we knew the data wasn't as open as it is now, with a simple pg
> restart it is all
> open?
>
> Can this only be done by maybe modifying the source to make pg_hba
> fields statically
> compiled into the executable?
>
Instead, you might want to read about SELinux.
You can protect files even to root (unless they
reboot but really you should have only trusted
people have admin accounts. How comes you have
somebody untrusted as admin?

Regards
Tino

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

To give it to you straight... its just to ease the minds of management.

Someone pointed out to them how easy it really is to access the data, and
this kind of started to make them feel uncomfortable.

They know the admins are very computer literate and that any protection
can be broken by them.

But it's just like information locked inside a cabinet, it can be
accessed by breaking in
right? But employees wont do it, because it's just not ethical to break
into your
employers private stash. But if it was lying on a paper on a desk
somewhere,
even the most honest employee might peek onto it for interest sake.

And this type of information can stir quite a bit, trust me.

That is all I was wondering about, if there was a way to just lock it
inside a
cabinet with a tiny bit more security.

After that you can always take measures to make sure they aren't
installing malicious
software, or taking information home. You can install software like
Tripwire to make
sure the binaries are kept fine, remove gcc and so forth.

Tino Wildenhain wrote:

> Q Beukes schrieb:
>
>> Well,
>>
>> I am not looking for 100% security. I know that full access if full
>> access,
>> and that even if you were to encrypt the system through Postgre the
>> determined
>> person WILL always be able to get it out if they have system level
>> access.
>>
>> All I wanted to do was to prevent the basic SQL/Linux literate user from
>> accessing
>> the databases. At the moment it is very easy for them to access the
>> data.
>>
>> I trust that they wont go as far as overwriting the system with custom
>> compiled
>> version, or copying the data and so forth. It just that we would feel
>> much better
>> if we knew the data wasn't as open as it is now, with a simple pg
>> restart it is all
>> open?
>>
>> Can this only be done by maybe modifying the source to make pg_hba
>> fields statically
>> compiled into the executable?
>>
> Instead, you might want to read about SELinux.
> You can protect files even to root (unless they
> reboot but really you should have only trusted
> people have admin accounts. How comes you have
> somebody untrusted as admin?
>
> Regards
> Tino
>

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org