Re: sandboxing untrusted code

Hi,

On 2026-04-18 15:26:33 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > Returning to this topic after some time, I have realized that both of
> > these rules are inadequate.
> > ... As soon as
> > the attacker has *any* influence over what code the victim calls,
> > there's a danger of a "confused deputy" attack.
>
> 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.
>
> 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.

Greetings,

Andres Freund