Specification for Trusted PLs?
in [PgSql]
|
From: Tom Lane on 21 May 2010 16:04 Joshua Tolley <eggyknap(a)gmail.com> writes: > Agreed. As long as a trusted language can do things outside the > database only by going through a database and calling some function to > which the user has rights, in an untrusted language, that seems decent > to me. A user with permissions to launch_missiles() would have a > function in an untrusted language to do it, but there's no reason an > untrusted language shouldn't be able to say "SELECT s/untrusted/trusted/ here, right? > launch_missiles()". To me, as long as they go back into the database via SPI, anything they can get to from there is OK. What I meant to highlight upthread is that we don't want trusted functions being able to access other functions "directly" without going through SQL. As an example, a PL that has FFI capability sufficient to allow direct access to heap_insert() would have to be considered untrusted. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jonathan Leto on 21 May 2010 16:08 Howdy, On Fri, May 21, 2010 at 11:21 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> So... can we get back to coming up with a reasonable >> definition, > > (1) no access to system calls (including file and network I/O) > > (2) no access to process memory, other than variables defined within the > PL. > > What else? I ran across this comment in PL/Perl while implementing PL/Parrot, and I think it should be taken into consideration for the definition of trusted/untrusted: /* * plperl.on_plperl_init is currently PGC_SUSET to avoid issues whereby a * user who doesn't have USAGE privileges on the plperl language could * possibly use SET plperl.on_plperl_init='...' to influence the behaviour * of any existing plperl function that they can EXECUTE (which may be * security definer). Set * http://archives.postgresql.org/pgsql-hackers/2010-02/msg00281.php and * the overall thread. */ Duke -- Jonathan "Duke" Leto jonathan(a)leto.net http://leto.net -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Joshua Tolley on 21 May 2010 16:21 On Fri, May 21, 2010 at 2:04 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Joshua Tolley <eggyknap(a)gmail.com> writes: >> Agreed. As long as a trusted language can do things outside the >> database only by going through a database and calling some function to >> which the user has rights, in an untrusted language, that seems decent >> to me. A user with permissions to launch_missiles() would have a >> function in an untrusted language to do it, but there's no reason an >> untrusted language shouldn't be able to say "SELECT > > s/untrusted/trusted/ here, right? Er, right. Sorry. > >> launch_missiles()". > > To me, as long as they go back into the database via SPI, anything they > can get to from there is OK. What I meant to highlight upthread is that > we don't want trusted functions being able to access other functions > "directly" without going through SQL. As an example, a PL that has FFI > capability sufficient to allow direct access to heap_insert() would > have to be considered untrusted. That I can definitely agree with. -- Joshua Tolley / eggyknap End Point Corporation -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jan Wieck on 21 May 2010 17:05 The original idea was that a trusted language does not allow an unprivileged user to gain access to any object or data, he does not have access to without that language. This does not include data transformation functionality, like string processing or the like. As long as the user had legitimate access to the input datum, then every derived form thereof is OK. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alexey Klyukin on 22 May 2010 04:45
On Fri, May 21, 2010 at 7:25 PM, Magnus Hagander <magnus(a)hagander.net> wrote: > On Fri, May 21, 2010 at 12:22 PM, David Fetter <david(a)fetter.org> wrote: >> On Fri, May 21, 2010 at 11:57:33AM -0400, Magnus Hagander wrote: >>> On Fri, May 21, 2010 at 11:55 AM, Josh Berkus <josh(a)agliodbs.com> wrote: >>> > So, here's a working definition: >>> > >>> > 1) cannot directly read or write files on the server. >>> > 2) cannot bind network ports >>> >>> To make that more covering, don't yu really need something like >>> "cannot communicate with outside processes"? >> >> These need to be testable conditions, and new tests need to get added >> any time we find that we've missed something. Making this concept >> fuzzier is exactly the wrong direction to go. > > Well, the best way to define what a trusted language can do is to > define a *whitelist* of what it can do, not a blacklist of what it > can't do. That's the only way to get a complete definition. It's then > up to the implementation step to figure out how to represent that in > the form of tests. Yes, PL/Perl is following this approach. For a whitelist see plperl_opmask.h (generated by plperl_opmask.pl at build phase). -- Alexey Klyukin www.CommandPrompt.com The PostgreSQL Company - Command Prompt, Inc -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |