[ADMIN] Disable TRUST authentication mode

[c k]

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

[Jan Lentfer]

Post by c k
Can we disable the trust authentication mode?

[...]

Post by c k
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

[c k]

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

Post by c k
Can we disable the trust authentication mode?
[...]
What steps we can take to prevent such access or to disable the TRUST

Post by c k
mode completely?

Sorry, maybe I do not entirely understand what you mean, but just >don't
use< trust in you pg_hba.conf?
Jan
--
http://www.postgresql.org/**mailpref/pgsql-admin<http://www.postgresql.org/mailpref/pgsql-admin>

[Frank Lanitz]

On Sat, 10 Mar 2012 20:45:38 +0530

Post by c k
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

[Jan Lentfer]

Post by 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

[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.

C P Kulkarni

Post by Jan Lentfer
Sorry, maybe I do not entirely understand what you mean, but just >don't

Post by Jan Lentfer
use< trust in you pg_hba.conf?

"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
--
http://www.postgresql.org/**mailpref/pgsql-admin<http://www.postgresql.org/mailpref/pgsql-admin>

[Frank Lanitz]

On Sat, 10 Mar 2012 20:51:58 +0530

Post by 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.

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

[Jan Lentfer]

Post by 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

[Tom Lane]

Post by Jan Lentfer

Post by 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

[c k]

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

Post by c k
It we can disable the TRUST mode then every user have to login with

Post by c k
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
--
http://www.postgresql.org/**mailpref/pgsql-admin<http://www.postgresql.org/mailpref/pgsql-admin>

[Frank Lanitz]

On Sat, 10 Mar 2012 21:50:32 +0530

Post by c k
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

[Kevin Grittner]

Post by c k
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