Thread: security flaw

security flaw

From
ohp@pyrenet.fr
Date:
Hi all,

I wonder if it's a security problem: One of my customer noticed that he
could see all databases on the system with phppgadmin. not only he sees
databases but tables, views, fonctions... Fortunatly he can't see any row.

This customer has the ability to create databases but not users.
I wonder if the super_user privilege should be separated from the
priviledge of creating databases/users.

I alose think that only a superuser should list databases and objects.

What do you think?

Regards

-- 
Olivier PRENANT             Tel:    +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                      +33-6-07-63-80-64 (GSM)
FRANCE                      Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


Re: security flaw

From
Robert Treat
Date:
On Sat, 2003-06-07 at 14:04, ohp@pyrenet.fr wrote:
> Hi all,
> 
> I wonder if it's a security problem: One of my customer noticed that he
> could see all databases on the system with phppgadmin. not only he sees
> databases but tables, views, fonctions... Fortunatly he can't see any row.
> 
> This customer has the ability to create databases but not users.
> I wonder if the super_user privilege should be separated from the
> priviledge of creating databases/users.
> 
> I alose think that only a superuser should list databases and objects.
> 
> What do you think?

phppgadmin has some options to hide some of this information, but
clearly understand that users can always submit arbitrary sql to get the
same information, so you'd have to change the back end's security model
to really keep people from finding this kind of information out. I know
many of our users would welcome that change.

Robert Treat
phpPgAdmin Team 
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



Re: security flaw

From
"scott.marlowe"
Date:
On Sat, 7 Jun 2003 ohp@pyrenet.fr wrote:

> Hi all,
> 
> I wonder if it's a security problem: One of my customer noticed that he
> could see all databases on the system with phppgadmin. not only he sees
> databases but tables, views, fonctions... Fortunatly he can't see any row.
> 
> This customer has the ability to create databases but not users.
> I wonder if the super_user privilege should be separated from the
> priviledge of creating databases/users.
> 
> I alose think that only a superuser should list databases and objects.
> 
> What do you think?

Since security by obscurity is presumed to be ineffective, conversely, 
revealing the location of an object produces no real decrease in security.

Now, it might be nice from the user's perspective if they could filter out 
the stuff they don't have access to, in order to ensure a nice neat little 
view of their own data in a galaxy of information (i.e. 100 other users 
each with their own data set and priveldges.)

Since schemas provide a simple way to limit your own view, they provide 
for that function.

Can phppgadmin be programmed to only use certain search paths in the 
schema?



Re: security flaw

From
ohp@pyrenet.fr
Date:
On Tue, 10 Jun 2003, scott.marlowe wrote:

> Date: Tue, 10 Jun 2003 08:15:06 -0600 (MDT)
> From: scott.marlowe <scott.marlowe@ihs.com>
> To: ohp@pyrenet.fr
> Cc: pgsql-hackers list <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] security flaw
>
> On Sat, 7 Jun 2003 ohp@pyrenet.fr wrote:
>
> > Hi all,
> >
> > I wonder if it's a security problem: One of my customer noticed that he
> > could see all databases on the system with phppgadmin. not only he sees
> > databases but tables, views, fonctions... Fortunatly he can't see any row.
> >
> > This customer has the ability to create databases but not users.
> > I wonder if the super_user privilege should be separated from the
> > priviledge of creating databases/users.
> >
> > I alose think that only a superuser should list databases and objects.
> >
> > What do you think?
>
> Since security by obscurity is presumed to be ineffective, conversely,
> revealing the location of an object produces no real decrease in security.
>
> Now, it might be nice from the user's perspective if they could filter out
> the stuff they don't have access to, in order to ensure a nice neat little
> view of their own data in a galaxy of information (i.e. 100 other users
> each with their own data set and priveldges.)
>
> Since schemas provide a simple way to limit your own view, they provide
> for that function.
>
> Can phppgadmin be programmed to only use certain search paths in the
> schema?
>
>
Hmm. Surely I did'nt make myself clear, PhpPgAdmin is not a problm here.
The problem is user A is owner of databses X1,Y1 Z1
user B is owner of databases X2,Yé,Z2

both users can see the the others DB. by doing a simple \l
It would be nice that unless a user is superuser he could'nt see databases
that are not his.

BTW how can I change ownership of databases and tables easealy?

-- 
Olivier PRENANT             Tel:    +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou           +33-5-61-50-97-01 (Fax)
31190 AUTERIVE                      +33-6-07-63-80-64 (GSM)
FRANCE                      Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


Re: security flaw

From
"Christopher Kings-Lynne"
Date:
> Since schemas provide a simple way to limit your own view, they provide
> for that function.
>
> Can phppgadmin be programmed to only use certain search paths in the
> schema?

Not at the moment. The only control you have is 'show only owned databases'.
'Show only owned schemas' is also quite easy.  Even better would be if I
filtered the list of schemas by 'has_object_privilege(schemaoid, 'USAGE')'
or however that function works.

The general philosophy of phpPgAdmin is to allow everything that PostgreSQL
allows and don't try to be clever about restricting things because such
restrictions are pure fantasy since we let people execute whatever SQL they
want.

Chris