Specification for Trusted PLs?
in [PgSql]
|
From: Tom Lane on 21 May 2010 15:13 "Greg Sabino Mullane" <greg(a)turnstep.com> writes: >> 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. > No, that's exactly backwards. We can't define all the things a language > can do, but we can certainly lay out the things that it is not supposed to. Yeah. The whole point of allowing multiple PLs is that some of them make it possible/easy to do things you can't (easily) do in others. So I'm not sure that a whitelist is going to be especially useful. 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: Tom Lane on 21 May 2010 15:15 Robert Haas <robertmhaas(a)gmail.com> writes: > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> (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. As long as you can't do database access except via SPI, that should be covered. So I guess the next item on the list is no, or at least restricted, access to functions outside the PL's own language. 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: David Fetter on 21 May 2010 15:36 On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > >> (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. > > As long as you can't do database access except via SPI, that should > be covered. So I guess the next item on the list is no, or at least > restricted, access to functions outside the PL's own language. "No access" seems pretty draconian. How about limiting such access to functions of equal or lower trustedness? Surely an untrusted function shouldn't be restricted from calling other untrusted functions based on the language they're written in. Cheers, David (who is not, at this point, going to suggest that a "trusted" boolean may inadequately reflect users' needs) -- 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: David Fetter on 21 May 2010 15:40 On Fri, May 21, 2010 at 12:36:50PM -0700, David Fetter wrote: > On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote: > > Robert Haas <robertmhaas(a)gmail.com> writes: > > > On Fri, May 21, 2010 at 2:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > >> (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. > > > > As long as you can't do database access except via SPI, that should > > be covered. So I guess the next item on the list is no, or at least > > restricted, access to functions outside the PL's own language. > > "No access" seems pretty draconian. > > How about limiting such access to functions of equal or lower > trustedness? I see that's confusing. What I meant was that functions in trusted languages should be able to call other functions in trusted languages, while functions in untrusted languages shouldn't be restricted as to what other functions they can call. 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: Joshua Tolley on 21 May 2010 15:55
On Fri, May 21, 2010 at 1:36 PM, David Fetter <david(a)fetter.org> wrote: > On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote: >> As long as you can't do database access except via SPI, that should >> be covered. So I guess the next item on the list is no, or at least >> restricted, access to functions outside the PL's own language. > > "No access" seems pretty draconian. > > How about limiting such access to functions of equal or lower > trustedness? Surely an untrusted function shouldn't be restricted > from calling other untrusted functions based on the language they're > written in. 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 launch_missiles()". -- 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 |