On 07/21/2013 10:30 PM, Markus Wanner wrote:
>> but I will admit having a hard time swallowing
>> the threat model we're talking about…
> An attacker having access to a libpq connection with superuser rights
> cannot currently run arbitrary native code. He can try a DOS by
> exhausting system resources, but that's pretty far from being
> invisible. Or he can delete valuable data. Maybe other nasty things. But
> he should not be able to gain root access and remove its traces.
>
> Dropping this barrier by installing an untrusted PL (or equally insecure
> extensions), an attacker with superuser rights can trivially gain
> root.
Could you elaborate ?
This is equivalent to claiming that any linux user can trivially gain root.
>>> If the sysadmin wants to disallow arbitrary execution of native code to
>>> postgres (the process), any kind of embedded compiler likely is equally
>>> unwelcome.
>> You already mentioned untrusted PL languages, and I don't see any
>> difference in between offering PL/pythonu and PL/C on security grounds,
>> really.
> I agree. However, this also means that any kind of solution it offers is
> not a good one for the security conscious sysadmin.
This is usually the case with a "security conscious sysadmin" - they very
seldom want to install anything.
A "cloud style" solution to this problem is installing the whole
PostgreSQL
host in its own VM and deklegate all security to developers ;)
>
> Regards
>
> Markus Wanner
>
>
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ