| From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> | 
|---|---|
| To: | Eric Lauzon <eric(dot)lauzon(at)abovesecurity(dot)com> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: plpgsql by default | 
| Date: | 2006-04-12 17:24:19 | 
| Message-ID: | 443D37C3.1090702@pse-consulting.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Eric Lauzon wrote:
>>-----Original Message-----
>>From: pgsql-hackers-owner(at)postgresql(dot)org 
>>[mailto:pgsql-hackers-owner(at)postgresql(dot)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(at)supernews(dot)com; pgsql-hackers(at)postgresql(dot)org
>>Subject: Re: [HACKERS] plpgsql by default
>>
>>On 4/11/06, Neil Conway <neilc(at)samurai(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2006-04-12 17:39:09 | Re: Practical impediment to supporting multiple SSL libraries | 
| Previous Message | Eric Lauzon | 2006-04-12 17:16:24 | Re: plpgsql by default |