Specification for Trusted PLs?

* David Fetter (david@fetter.org) wrote:

I have been looking for a document which specifies what trusted and
untrusted PLs must do and forbid, so far without result.

I think you might have been missing the tree for the forest in this
case.. :) I'm sure you've seen this, but perhaps you weren't thinking
about how broad it really is:

http://www.postgresql.org/docs/9.0/static/sql-createlanguage.html

TRUSTED

TRUSTED specifies that the language is safe, that is, it does not
offer an unprivileged user any functionality to bypass access
restrictions. If this key word is omitted when registering the
language, only users with the PostgreSQL superuser privilege can use
this language to create new functions.

That's about it- a language is TRUSTED if there's no way for a user to
be able to write a function which will give them access to things
they're not supposed to have. Practically, this includes things like
any kind of direct I/O (files, network, etc).

Where do we document this, and if we don't where *should* we document
this?

I'd be hesitant about trying to document exactly what a PL must do to be
trusted at a more granular level than what's above- mostly because, if
we change some functionality, we would end up having to document that
change in the place which is appropriate for it and then also in the
list of "things trusted PLs shouldn't do/allow".

Thanks,

Stephen

That's about it- a language is TRUSTED if there's no way for a user to
be able to write a function which will give them access to things
they're not supposed to have.  Practically, this includes things like
any kind of direct I/O (files, network, etc).

The fact that plpythonu used to be plpython back in 7.3 serves to
illustrate that the distinction is not all that well defined. I guess
that someone made an executive decision that the python restricted
execution environment wasn't restricted enough.

Regards,
Peter Geoghegan

Peter Geoghegan <peter.geoghegan86@gmail.com> writes:

That's about it- a language is TRUSTED if there's no way for a user to
be able to write a function which will give them access to things
they're not supposed to have. �Practically, this includes things like
any kind of direct I/O (files, network, etc).

The fact that plpythonu used to be plpython back in 7.3 serves to
illustrate that the distinction is not all that well defined. I guess
that someone made an executive decision that the python restricted
execution environment wasn't restricted enough.

Well, it was the upstream authors of python's restricted execution
environment who decided it was unfixably insecure, not us. So the
"trusted" version had to go away.

(For awhile there last month, it was looking like plperl was going to
suffer the same fate :-(. Fortunately Tim Bunce thought of a way to
not have to rely on Safe.pm anymore.)

regards, tom lane

So, here's a working definition:

1) cannot directly read or write files on the server.
2) cannot bind network ports
3) uses only the SPI interface to interact with postgresql tables etc.
4) does any logging only using elog to the postgres log

Questions:

a) it seems like there should be some kind of restriction on access to
memory, but I'm not clear on how that would be defined.

b) where are we with the whole trusted module thing? Like for CPAN
modules etc.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Fri, May 21, 2010 at 11:55 AM, Josh Berkus <josh@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"?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On 05/21/2010 11:57 AM, Magnus Hagander wrote:

On Fri, May 21, 2010 at 11:55 AM, Josh Berkus<josh@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"?

So, no interprocess communication except through the SPI interface? How
do module GUCs and things like %_SHARED fit into this?

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

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@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.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@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

On Fri, May 21, 2010 at 12:22 PM, David Fetter <david@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@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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

* David Fetter (david@fetter.org) wrote:

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.

I'm really not sure that we want to be in the business of writing a ton
of regression tests to see if languages which claim to be trusted really
are..

Stephen

On Fri, May 21, 2010 at 12:26:24PM -0400, Stephen Frost wrote:

* David Fetter (david@fetter.org) wrote:

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.

I'm really not sure that we want to be in the business of writing a
ton of regression tests to see if languages which claim to be
trusted really are..

That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@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

* David Fetter (david@fetter.org) wrote:

That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.

k, let's start with something simpler first tho- I'm sure we can pull in
the glibc regression tests and run them too. You know, just in case
there's a bug there, somewhere.

Thanks,

Stephen

On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:

* David Fetter (david@fetter.org) wrote:

That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.

k, let's start with something simpler first tho- I'm sure we can pull in
the glibc regression tests and run them too. You know, just in case
there's a bug there, somewhere.

That's pretty pure straw man argument. I expect much higher quality
trolling. D-.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@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

On May 21, 2010, at 18:26 , Stephen Frost wrote:

* David Fetter (david@fetter.org) wrote:

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.

I'm really not sure that we want to be in the business of writing a ton
of regression tests to see if languages which claim to be trusted really
are..

Well, testing software security via regression tests certainly is sounds intriguing. But unfortunately, it's impossible also AFAICS - it'd amount to testing for the *absence* of features, which seems hard...

I suggest the following definition of "trusted PL".
"While potentially preventing excruciating pain, saving tons of sweat and allowing code reuse, actually adds nothing in terms of features over pl/pgsql".

best regards,
Florian Pflug

* David Fetter (david@fetter.org) wrote:

On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:

k, let's start with something simpler first tho- I'm sure we can pull in
the glibc regression tests and run them too. You know, just in case
there's a bug there, somewhere.

That's pretty pure straw man argument. I expect much higher quality
trolling. D-.

Sorry, but seriously, at some point we have to expect that the tools we
use will behave according to their claims and their documentation, at
least until proven otherwise. I don't like that it means we may end up
having to issue CVE's when there are issues in things we use, but I
don't think that means we shouldn't use other libraries or we should
spend alot of time working on validating those tools. Presumably, they
have communities who do that.

As an example, consider the zlib issue that happened not too long ago
and the subsequent many CVE's that came of it. We could have reviewed
zlib better and possibly found that bug, but I don't know that it would
be the best use of our rather limited resources. Additionally, trying
to go into other code bases like that to do that kind of detailed review
would necessairly be much more difficult for those who are not familiar
with it. etc, etc...

Stephen

David Fetter <david@fetter.org> writes:

On Fri, May 21, 2010 at 12:26:24PM -0400, Stephen Frost wrote:

I'm really not sure that we want to be in the business of writing a
ton of regression tests to see if languages which claim to be
trusted really are..

That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.

I can't see us writing an AI-complete set of tests for each language
we ship, let alone ones we don't. Testing can prove the presence of
bugs, not their absence --- and that applies in spades to security
holes.

regards, tom lane

On Fri, May 21, 2010 at 1:58 PM, David Fetter <david@fetter.org> wrote:

On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:

* David Fetter (david@fetter.org) wrote:

That is *precisely* the business we need to be in, at least for the
languages we ship, and it would behoove us to test languages we don't
ship so we can warn people when they don't pass.

k, let's start with something simpler first tho- I'm sure we can pull in
the glibc regression tests and run them too.  You know, just in case
there's a bug there, somewhere.

That's pretty pure straw man argument.  I expect much higher quality
trolling.  D-.

I'm sorely tempted to try to provide some higher-quality trolling, but
in all seriousness I think that (1) we could certainly use much better
regression tests in many areas of which this is one and (2) it will
never be possible to catch all security bugs - in particular - via
regression testing because they typically stem from cases people
didn't consider. So... can we get back to coming up with a reasonable
definition, and if somebody wants to write some regression tests, all
the better?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas@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?

regards, tom lane

On Fri, May 21, 2010 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-----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.

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.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201005211452
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkv21oIACgkQvJuQZxSWSsg8lQCdFKNXO5XWD5bJ0lQAx3prFYGW
5CYAnjHiuwKVAxvwjl/clyiwCtXCVvr0
=5tSD
-----END PGP SIGNATURE-----