Thread: Re: plpgsql by default

Re: plpgsql by default

From
"Eric Lauzon"
Date:
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of
> Merlin Moncure
> Sent: 12 avril 2006 12:22
> To: Neil Conway
> Cc: Tom Lane; David Fetter; Jim C. Nasby; Joshua D. Drake;
> andrew@supernews.com; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] plpgsql by default
>
> On 4/11/06, Neil Conway <neilc@samurai.com> wrote:
> > On Tue, 2006-04-11 at 17:20 -0400, Tom Lane wrote:
> > > No, I'm saying that having access to a PL renders certain
> classes of
> > > attacks significantly more efficient.  A determined attacker with
> > > unlimited time may not care, but in the real world, security is
> > > relative.
> >
> > That's a fair point.
> >
> > Perhaps a compromise would be to enable pl/pgsql by
> default, but not
> > grant the USAGE privilege on it. This would allow
> superusers to define
>


One way to circumvent the hassle of having to create
the language is to create the database from a template
that has the language , hence semi-default plpgsql handler
by "default".

On the security side, if you implement strong ACLS on the data
manipulation
if the database is compromised to a level where a low priviliged user
database access
is compromised there shouldn't be any danger toward having them using
SQL or plpgsql.

The dark side of this could be some type of privilege escalation scheme
present
inside postgresql.

As example MS-SQL xp_* stored proc, are a vulnerability vector if the
compromised user
can execute them.

So if by default the attacked application is running as the "postgres"
user, what will you do to
prevent them from manipulating internal's? :)

-elz

AVERTISSEMENT CONCERNANT LA CONFIDENTIALITE

Le present message est a l'usage exclusif du ou des destinataires mentionnes ci-dessus. Son contenu est confidentiel et
peutetre assujetti au secret professionnel. Si vous avez recu le present message par erreur, veuillez nous en aviser
immediatementet le detruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite. 

CONFIDENTIALITY NOTICE

This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and
maycontain privileged information. If you have received this communication by error, please notify the sender and
deletethe message without copying or disclosing it. 


Re: plpgsql by default

From
Andreas Pflug
Date:
Eric Lauzon wrote:
>>-----Original Message-----
>>From: pgsql-hackers-owner@postgresql.org 
>>[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of 
>>Merlin Moncure
>>Sent: 12 avril 2006 12:22
>>To: Neil Conway
>>Cc: Tom Lane; David Fetter; Jim C. Nasby; Joshua D. Drake; 
>>andrew@supernews.com; pgsql-hackers@postgresql.org
>>Subject: Re: [HACKERS] plpgsql by default
>>
>>On 4/11/06, Neil Conway <neilc@samurai.com> wrote:
>>
>>>On Tue, 2006-04-11 at 17:20 -0400, Tom Lane wrote:
>>>
>>>>No, I'm saying that having access to a PL renders certain 
>>
>>classes of 
>>
>>>>attacks significantly more efficient.  A determined attacker with 
>>>>unlimited time may not care, but in the real world, security is 
>>>>relative.
>>>
>>>That's a fair point.
>>>
>>>Perhaps a compromise would be to enable pl/pgsql by 
>>
>>default, but not 
>>
>>>grant the USAGE privilege on it. This would allow 
>>
>>superusers to define
>>
> 
> 
> 
> One way to circumvent the hassle of having to create 
> the language is to create the database from a template 
> that has the language , hence semi-default plpgsql handler
> by "default".
> 
> On the security side, if you implement strong ACLS on the data
> manipulation
> if the database is compromised to a level where a low priviliged user
> database access
> is compromised there shouldn't be any danger toward having them using
> SQL or plpgsql.
> 
> The dark side of this could be some type of privilege escalation scheme
> present
> inside postgresql.
> 
> As example MS-SQL xp_* stored proc, are a vulnerability vector if the
> compromised user
> can execute them.
> 
> So if by default the attacked application is running as the "postgres"
> user, what will you do to
> prevent them from manipulating internal's? :)

This is just a little safer than surfing the internet with MSSQL 
installed and the sa user having no password :-)

I wonder if a less-privileged user should be present in the database by 
default, with some advise to use that user instead of postgres for 
standard connections. I wouldn't be surprised if >80 % of win32 pgsql 
installations have a single user only...

Regards,
Andreas