Specification for Trusted PLs?
in [PgSql]
|
From: =?ISO-8859-1?Q?C=E9dric_Villemain?= on 22 May 2010 16:53 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. > > > 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 > -- Cédric Villemain -- 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: Robert Haas on 22 May 2010 23:09 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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: Ron Mayer on 23 May 2010 18:14 Tom Lane 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) If a PL has file access to it's own sandbox (similar to what flash seems to do in web browsers), could that be considered trusted? -- 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 23 May 2010 21:16 On 5/23/2010 6:14 PM, Ron Mayer wrote: > Tom Lane 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) > > If a PL has file access to it's own sandbox (similar to what > flash seems to do in web browsers), could that be considered > trusted? That is a good question. Currently, the first of all TRUSTED languages, PL/Tcl, would allow the function of a lesser privileged user access the "global" objects of every other database user created within the same session. These are per backend in memory objects, but none the less, an evil function could just scan the per backend Tcl namespace and look for compromising data, and that's not exactly what TRUSTED is all about. In the case of Tcl it is possible to create a separate "safe" interpreter per DB role to fix this. I actually think this would be the right thing to do. 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: Andrew Dunstan on 23 May 2010 22:04
Jan Wieck wrote: > On 5/23/2010 6:14 PM, Ron Mayer wrote: >> Tom Lane 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) >> >> If a PL has file access to it's own sandbox (similar to what >> flash seems to do in web browsers), could that be considered >> trusted? > > That is a good question. > > Currently, the first of all TRUSTED languages, PL/Tcl, would allow the > function of a lesser privileged user access the "global" objects of > every other database user created within the same session. > > These are per backend in memory objects, but none the less, an evil > function could just scan the per backend Tcl namespace and look for > compromising data, and that's not exactly what TRUSTED is all about. > > In the case of Tcl it is possible to create a separate "safe" > interpreter per DB role to fix this. I actually think this would be > the right thing to do. > I think that would probably be serious overkill. Maybe a data stash per role rather than an interpreter per role would be doable. it would certainly be more lightweight. ISTM we are in danger of confusing several different things. A user that doesn't want data to be shared should not stash it in global objects. But to me, trusting a language is not about making data private, but about not allowing the user to do things that are dangerous, such as referencing memory, or the file system, or the operating system, or network connections, or loading code which might do any of those things. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |