Обсуждение: Disable TRUST authentication mode

Hi,
Can we disable the trust authentication mode?

One of our customer found that few of it's employees are trying to change the data without having any proper rights. The simplest way is to get the control of the server and then change the mode of the authentication to trust and restart the server. All other regular users will do not get any problems for their daily working. And this is the real fact that persons from IT department can be one of the users who are going to make a fraud.
Even after having sufficient logging and other preventative actions, like logging in the database for what is changed (audit trails) and even using postgresql logs, it impossible to prevent such things. As in most of the times we use username/password as basic functionality to prevent unauthorised users from getting the database access, TRUST makes a grand back door for hackers or fraud making users to get into the database. In TRUST mode knowing the name of the user is sufficient and it is not hard to know the superuser login name.

What steps we can take to prevent such access or to disable the TRUST mode completely?

Thanks,

C P Kulkarni

Am 10.03.2012 16:00, schrieb c k:

> Can we disable the trust authentication mode?

[...]

> What steps we can take to prevent such access or to disable the TRUST
> mode completely?

Sorry, maybe I do not entirely understand what you mean, but just >don't
use< trust in you pg_hba.conf?

Jan

I am not managing the customer database. The problem is related with the IT department of the customer who has the access to the database server and the fraud persons from this department can chnage the authentication to trust to get the access to database without knowing the passwords and even to superuser accounts.

C P Kulkarni

Am 10.03.2012 16:09, schrieb Jan Lentfer:
> Sorry, maybe I do not entirely understand what you mean, but just >don't
> use< trust in you pg_hba.conf?

Reading it again, I'd say this is your problem:

"The simplest way is >to get the control of the server< and then change
the mode of the authentication to trust and restart the server."


If anyone can do that with your server, how would disabling trust
improve anything?

Jan

On Sat, 10 Mar 2012 20:45:38 +0530
c k <shreeseva.learning@gmail.com> wrote:

> I am not managing the customer database. The problem is related with
> the IT department of the customer who has the access to the database
> server and the fraud persons from this department can chnage the
> authentication to trust to get the access to database without knowing
> the passwords and even to superuser accounts.

This most likely sounds like a social problem you _cannot_ solve with
technique. However, ensure users you don't trust are not allowed to
write pg_hba.conf e.g. by don't giving root/postgres-user rights on
that machine.

Cheers,
Frank
--
Frank Lanitz <frank@frank.uvena.de>

It we can disable the TRUST mode then every user have to login with password and every fraud user have to know the password (at least) of the user. It is not the case that users from other departments share their passwords, but fraud users just bypasses the need to know the password.

C P Kulkarni

On Sat, 10 Mar 2012 20:51:58 +0530
c k <shreeseva.learning@gmail.com> wrote:

> It we can disable the TRUST mode then every user have to login with
> password and every fraud user have to know the password (at least) of
> the user. It is not the case that users from other departments share
> their passwords, but fraud users just bypasses the need to know the
> password.

Users that are able to change pg_hba.conf are most likely also able to
replace any binary at the system. Even you are right that the trust
option is a bit dangerous, but its not your root issue.

Cheers,
Frank
--
Frank Lanitz <frank@frank.uvena.de>

Am 10.03.2012 16:21, schrieb c k:
> It we can disable the TRUST mode then every user have to login with
> password and every fraud user have to know the password (at least) of
> the user. It is not the case that users from other departments share
> their passwords, but fraud users just bypasses the need to know the
> password.

If they can alter pg_hba.conf they can almost certainly also change/add
users, alter passwords, etc, etc... So from a security perspective it
doesn't buy you much.

I don't know if you could build a custom postgresql from sources with
trust disabled. But it wouldn't be worth the trouble imo.

Jan

Jan Lentfer <Jan.Lentfer@web.de> writes:
> Am 10.03.2012 16:21, schrieb c k:
>> It we can disable the TRUST mode then every user have to login with
>> password and every fraud user have to know the password (at least) of
>> the user. It is not the case that users from other departments share
>> their passwords, but fraud users just bypasses the need to know the
>> password.

> If they can alter pg_hba.conf they can almost certainly also change/add
> users, alter passwords, etc, etc... So from a security perspective it
> doesn't buy you much.

Somebody who has the ability to rewrite pg_hba.conf could also go in and
physically alter the database files -- those are in the same directory
tree, with the same ownership and permissions, as pg_hba.conf.  If you
cannot trust people who have that level of access, you have a problem
that software cannot solve for you.  You need to rethink who has got
access to the machine running the database server, or at least who has
got root on it.

            regards, tom lane

Thanks to all.
I understand that the users who have the access to the system can also change binaries. We are also thinking about the same. Using a virtual server for the database with almost 80% of the system resource where even persons from the IT department does not have the root access and do not know passwords for the superusers of the database or do not have the access to the filesystem of the virtual server can be a solution. Is it?
If any postgresql user have the experience to deal with the situations like, please share your experiences.

Thanks and regards,

C P Kulkarni

c k  wrote:

> One of our customer found that few of it's employees are trying to
> change the data without having any proper rights. The simplest way
> is to get the control of the server and then change the mode of the
> authentication to trust and restart the server.

There's your problem right there.

I once had the great pleasure and honor of attending a luncheon where
Admiral Grace Hopper[1] spoke.  One of the topics she addressed was
security.  She emphasized that if someone has physical access to your
hardware, the game is over.  She asserted that if anyone in the room
gave her ten minutes alone with their computer, she could breach
security, and dared those in attendance to let her prove it.
(Nobody took her up on it.)

Without getting into gory details, I realize that there are
techniques which could make certain types of attack difficult even
with physical access, but there are some absolute security
deal-breakers.  If someone can log on to the OS running your database
as the root user, you had better trust that person, because they can
do pretty much anything.  Any sense that you're secure in the face of
an untrusted user with root access is purely illusionary.  What's to
stop them from creating a custom version of any software (including
PostgreSQL) which has a back-door access that lets them in?

It seems to me that you either need to look at providing your
software as a service, so that you retain control of the hardware, or
educate your customers on security principles.

-Kevin

[1] http://en.wikipedia.org/wiki/Grace_Hopper

On Sat, 10 Mar 2012 21:50:32 +0530
c k <shreeseva.learning@gmail.com> wrote:

> I understand that the users who have the access to the system can also
> change binaries. We are also thinking about the same. Using a virtual
> server for the database with almost 80% of the system resource where
> even persons from the IT department does not have the root access and
> do not know passwords for the superusers of the database or do not
> have the access to the filesystem of the virtual server can be a
> solution. Is it?

Well... maybe we should start at root of issue as this is what I still
don't understand: Why shouldn't have you staff access to the database?
Somebody has to administrate database.... If you need to keep content
of some tables secure, did you think about storing encrypted objects
inside database?

Cheers,
Frank
--
Frank Lanitz <frank@frank.uvena.de>