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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
