Re: Hardening PostgreSQL via (optional) ban on local file system access

From: Andres Freund <andres(at)anarazel(dot)de>
To: Hannu Krosing <hannuk(at)google(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Pang <robertpang(at)google(dot)com>
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access
Date: 2022-06-25 01:09:27
Message-ID: 20220625010927.mkzgtk237tfzp6yo@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-06-25 01:23:36 +0200, Hannu Krosing wrote:
> Are you claiming that one can manipulate PostgreSQL to do any file
> writes directly by manipulating pg_proc to call the functions "in a
> wrong way" ?

Yes.

> My impression was that this was largely fixed via disabling the old
> direct file calling convention, but then again I did not pay much
> attention at that time :)

It got a tad harder, that's all.

> So your suggestion would be to also include disabling access to at
> least pg_proc for creating C and internal functions and possibly some
> other system tables to remove this threat ?

No. I seriously doubt that pursuing this makes sense. Fundamentally, if you
found a way to escalate to superuser, you're superuser. Superuser can create
extensions etc. That's game over. Done.

You can of course make postgres drop a few privileges, to make it harder to
turn escalation-to-superuser into wider access to the whole system. That could
very well make sense - but of course there's quite a few things that postgres
needs to do to work, so there's significant limits to what you can do.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-06-25 01:30:26 Re: making relfilenodes 56 bits
Previous Message Andres Freund 2022-06-25 01:05:51 Re: [PATCH] Optimize json_lex_string by batching character copying