On 07/16/2013 09:14 PM, I wrote:
> But okay, you're saying we *have* and *want* a guarantee that even a
> superuser cannot execute arbitrary native code via libpq (at least in
> default installs w/o extensions).
I stand corrected and have to change my position, again. For the record:
We do not ha
Dimitri,
On 07/22/2013 08:44 PM, Dimitri Fontaine wrote:
> That's the trade-off we currently need to make to be able to ship with
> the current security protections we're talking about.
Anything wrong with shipping postgis-1.5.so and postgis-2.0.so, as I we
for Debian?
> Ok, here's the full work
Markus Wanner writes:
- per-installation (not even per-cluster) DSO availability
>
> Not sure what the issue is, here, but I agree that should be possible.
For any extension where the new package version is shipping the same .so
file name, you can only have one module on the whole system f
On 07/22/2013 12:11 AM, Hannu Krosing wrote:
>> 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 r
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 resou
Salut Dimitri,
On 07/20/2013 01:23 AM, Dimitri Fontaine wrote:
> Markus Wanner writes:
>>> - per-installation (not even per-cluster) DSO availability
>>>
>>> If you install PostGIS 1.5 on a system, then it's just impossible to
>>> bring another cluster (of the same PostgreSQL major vers
Markus Wanner writes:
>> - per-installation (not even per-cluster) DSO availability
>>
>> If you install PostGIS 1.5 on a system, then it's just impossible to
>> bring another cluster (of the same PostgreSQL major version), let
> On Debian, that should be well possible. Certainly instal
On 07/17/2013 08:52 PM, Dimitri Fontaine wrote:
> the next step of this discussion should be about talking about the
> problems we have and figuring out *if* we want to solve them, now that
> we managed to explicitely say what we want as a project.
>
> - per-installation (not even per-cluster) D
Markus Wanner writes:
> But okay, you're saying we *have* and *want* a guarantee that even a
> superuser cannot execute arbitrary native code via libpq (at least in
> default installs w/o extensions).
There are several problems confused into that sentence already. I think
the next step of this di
On Tue, Jul 16, 2013 at 3:14 PM, Markus Wanner wrote:
> But okay, you're saying we *have* and *want* a guarantee that even a
> superuser cannot execute arbitrary native code via libpq (at least in
> default installs w/o extensions).
Yes, that's a good way of summarizing my position. I think I'd
On 07/16/2013 01:27 AM, Robert Haas wrote:
> Andres points out that you can install adminpack to obtain
> local filesystem access, and that is true. But the system
> administrator can also refuse to allow adminpack, and/or use selinux
> or other mechanisms to prevent the postgres binary from writi
On Mon, Jul 15, 2013 at 9:27 AM, Markus Wanner wrote:
> To clarify: In the above agreement, I had the Postgres level ordinary
> users in mind, who certainly shouldn't ever be able to upload and run
> arbitrary native code.
>
> I'm not quite as enthusiastic if you meant the system level user that
>
Robert,
On 07/15/2013 12:12 PM, Markus Wanner wrote:
> On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
>> There is a lot of
>> (well-founded, IMHO) resistance to the idea of letting users install C
>> code via an SQL connection.
>
> Nowhere did I propose anything close
On 07/15/2013 12:19 PM, Andres Freund wrote:
> On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
>> Granted, the "internalization" of the DSO is somewhat critical to
>> implement. Running as a non-root user, Postgres has less power than that
>> and can certainly not protect the internalized DSO fr
On 2013-07-15 12:20:15 +0200, Markus Wanner wrote:
> On 07/15/2013 12:05 PM, Andres Freund wrote:
> > A superuser can execute native code as postges user. That's it.
>
> Oh, I though Robert meant postgres users, i.e. non-superusers.
Oh, I am talking about *postgres* superusers ;). The example pro
On 07/15/2013 12:05 PM, Andres Freund wrote:
> A superuser can execute native code as postges user. That's it.
Oh, I though Robert meant postgres users, i.e. non-superusers.
I hereby withdraw my pitchforks: I'm certainly not opposing to simplify
the life of superusers, who already have the power.
On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
> Granted, the "internalization" of the DSO is somewhat critical to
> implement. Running as a non-root user, Postgres has less power than that
> and can certainly not protect the internalized DSO from modification by
> root. It can, however, store
Robert,
thanks for answering. I think you responded to the (or some) idea in
general, as I didn't see any relation to the quoted part. (Otherwise
this is a hint that I've not been clear enough.)
On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
> There is a lot of
> (well
On 2013-07-14 23:49:47 -0400, Robert Haas wrote:
> On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner wrote:
> > One way to resolve that - and that seems to be the direction Dimitri's
> > patch is going - is to make the extension depend on its template. (And
> > thereby breaking the mental model of a t
On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner wrote:
> One way to resolve that - and that seems to be the direction Dimitri's
> patch is going - is to make the extension depend on its template. (And
> thereby breaking the mental model of a template, IMO. In the spirit of
> that mental model, one c
20 matches
Mail list logo
