Re: sandboxing untrusted code

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Subject: Re: sandboxing untrusted code
Date: 2026-04-18 20:04:55
Message-ID: CA+Tgmob5A2n39cyXvUaAg_1cA5qE1NSTOqt-sStshi+f7F6QHg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 18, 2026 at 3:33 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > This is true, but I think it's hopeless to imagine that a technical
> > solution can stop that type of attack altogether. The deception
> > might happen entirely outside our system; the classical example
> > being where somebody persuades you to copy-and-paste some shell
> > code into your terminal window without fully understanding it.

Absolutely. I'm confident we can't prevent that attack with any sort
of technological safeguard, and trying would be a bad idea.

> > It's certainly likely that there's room for improvement of your
> > sandboxing ideas, but you shouldn't abandon them because they don't
> > solve some insoluble problems. If we can make large classes of
> > attacks infeasible at reasonable cost, we've still accomplished
> > a lot.
>
> Agreed. Even if there are some holes, it sounds like it'd rather drastically
> increase the likelihood of making such subversion attempts noticeable. That on
> its own is extremely valuable.

Thanks to both of you for the quick and encouraging responses. To be
clear, I wasn't planning to give up, but I did think it was worth
documenting the discovery of a clear oversight in my previous
proposal. It's actually a bit unclear to me how feasible "argument
choosing" attacks are (where you try to get the bad action to happen
while the victim's code or the code of someone they trust is running)
as compared with direct attacks (where your code tries to do a bad
action directly while running with their privileges). However, my
guess is that the answer is "feasible enough that we'd be pretty silly
to ignore that risk while designing a feature of this type".
Obviously, the perfect can be the enemy of the good, but equally, an
insufficiently ambitious scope can result into doing a lot of work for
very little actual gain.

At any rate, it's not time to make a scope decision yet: more research
is needed before committing deeply to any particular course of action.
I'm happy to hear your thoughts but let's reserve judgement until the
research is in.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2026-04-18 22:46:00 Re: Adding REPACK [concurrently]
Previous Message Andres Freund 2026-04-18 19:33:53 Re: sandboxing untrusted code