Re: Hardening PostgreSQL via (optional) ban on local file system access - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Hardening PostgreSQL via (optional) ban on local file system access
Date
Msg-id 20220625010927.mkzgtk237tfzp6yo@alap3.anarazel.de
Whole thread Raw
In response to Re: Hardening PostgreSQL via (optional) ban on local file system access  (Hannu Krosing <hannuk@google.com>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Optimize json_lex_string by batching character copying
Next
From: Andres Freund
Date:
Subject: Re: making relfilenodes 56 bits