Specification for Trusted PLs?
in [PgSql]
|
From: "Greg Sabino Mullane" on 24 May 2010 10:25 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> 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). Ah, okay, I can mostly agree with that. My objection was with trying to build a cross-language generic whitelist. But it looks like the ship has already sailed upthread and we've more or less got a working definition. David, I think you started this thread, I assume you have some concrete reason for asking about this (new trusted language?). May have been stated, but I missed it. - -- Greg Sabino Mullane greg(a)turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201005241025 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkv6jE4ACgkQvJuQZxSWSsjWugCdEwR/n0V3IeFB7w/h5hhPQW/J ln0An2FZKa2CHWaWdHKOvQvEbBIvyzwK =wqO5 -----END PGP SIGNATURE----- -- 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: Bruce Momjian on 27 May 2010 11:23 Tom Lane 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? One thing that has always bugged me is that the use of "trusted/untrusted" for languages is confusing, because it is "trusted" users who can run untrusted languages. I think "trust" is more associated with users than with software features. I have no idea how this confusion could be clarified. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- 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: David Fetter on 27 May 2010 15:30 On Thu, May 27, 2010 at 11:23:44AM -0400, Bruce Momjian wrote: > Tom Lane 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? > > One thing that has always bugged me is that the use of > "trusted/untrusted" for languages is confusing, because it is > "trusted" users who can run untrusted languages. I think "trust" is > more associated with users than with software features. I have no > idea how this confusion could be clarified. Sadly, I don't think it could short of a time machine. We're stuck with an backward convention. :( Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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: Peter Eisentraut on 27 May 2010 18:03 On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote: > On Fri, May 21, 2010 at 2:21 PM, 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? > > Doesn't subvert the general PostgreSQL security mechanisms? Not sure > how to formulate that. Succinctly: A trusted language does not grant access to data that the user would otherwise not have. I wouldn't go any further than that. File and network I/O, for example, are implementation details. A trusted language might do some kind of RPC, for example. The PL/J project once wanted to do something like that. -- 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: Bruce Momjian on 29 May 2010 22:23
Robert Haas wrote: > On Sat, May 22, 2010 at 4:53 PM, C?dric Villemain > <cedric.villemain.debian(a)gmail.com> wrote: > > 2010/5/21 Jan Wieck <JanWieck(a)yahoo.com>: > >> 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. > > > > I find the current doc enough, add this prose from Jan as a comment > > might help people perhaps. > > Yeah, Jan's description is very clear and to the point. The attached, applied patch clarifies the meaning of "trusted language" in the documentation using Jan's description. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com |