Re: [HACKERS] Specification for Trusted PLs?

2010-05-29 Thread Bruce Momjian
Robert Haas wrote:
 On Sat, May 22, 2010 at 4:53 PM, C?dric Villemain
 cedric.villemain.deb...@gmail.com wrote:
  2010/5/21 Jan Wieck janwi...@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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com
Index: doc/src/sgml/xplang.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/xplang.sgml,v
retrieving revision 1.37
diff -c -c -r1.37 xplang.sgml
*** doc/src/sgml/xplang.sgml	3 Apr 2010 07:22:56 -	1.37
--- doc/src/sgml/xplang.sgml	30 May 2010 02:21:53 -
***
*** 151,158 
  optionalVALIDATOR replaceablevalidator_function_name/replaceable/optional ;
  /synopsis
The optional key word literalTRUSTED/literal specifies that
!   ordinary database users that have no superuser privileges should
!   be allowed to use this language to create functions and trigger
procedures. Since PL functions are executed inside the database
server, the literalTRUSTED/literal flag should only be given
for languages that do not allow access to database server
--- 151,160 
  optionalVALIDATOR replaceablevalidator_function_name/replaceable/optional ;
  /synopsis
The optional key word literalTRUSTED/literal specifies that
!   the language does not grant access to data that the user would
!   not otherwise have.  Trusted languages are designed for ordinary
!   database users (those without superuser privilege) and allows them
!   to safely create of functions and trigger
procedures. Since PL functions are executed inside the database
server, the literalTRUSTED/literal flag should only be given
for languages that do not allow access to database server
Index: doc/src/sgml/ref/create_language.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/create_language.sgml,v
retrieving revision 1.50
diff -c -c -r1.50 create_language.sgml
*** doc/src/sgml/ref/create_language.sgml	3 Apr 2010 07:22:58 -	1.50
--- doc/src/sgml/ref/create_language.sgml	30 May 2010 02:21:53 -
***
*** 104,114 
  
   listitem
para
!literalTRUSTED/literal 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
 productnamePostgreSQL/productname superuser privilege can
 use this language to create new functions.
/para
--- 104,113 
  
   listitem
para
!literalTRUSTED/literal specifies that the language does
!not grant access to data that the user would not otherwise
!have.  If this key word is omitted
!when registering the language, only users with the
 productnamePostgreSQL/productname superuser privilege can
 use this language to create new functions.
/para

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-28 Thread Sam Mason
On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
 David Fetter da...@fetter.org writes:
  I don't know about a *good* idea, but here's the one I've got.
 
  1.  Make a whitelist.  This is what needs to work in order for a
  language to be a fully functional trusted PL.
 
 Well, I pretty much lose interest right here, because this is already
 assuming that every potentially trusted PL is isomorphic in its
 capabilities.

That's not normally a problem.  The conventional way would be to place
the interpreter in its own sandbox, similar to how Chrome has each tab
running in its own process.  These processes are protected in a way
so that the code running inside them can't do any harm--e.g. a ptrace
jail[1].  This is quite a change from existing pl implementations, and
present a different set of performance/compatibility issues.

 If that were so, there'd not be very much point in
 supporting multiple PLs.  A good example here is R.  I have no idea
 whether PL/R is trusted or trustworthy, but in any case the main point
 of supporting that PL is to allow access to the R statistical library.
 How does that fit into a whitelist designed for some other language?
 It doesn't.

AFAIU, a trusted language should only be able to perform computation,
e.g. not touch the local filesystem, beyond readonly access to library
code, and not see the network.  Policies such as these are easy to
enforce in a ptrace jail, and would still allow a trusted pl/r to do
whatever it wants to get any pure calculation done.  As soon as it needs
to touch the file system the language becomes non-trusted.

  3.  (the un-fun part) Write tests which attempt to do things not in
  the whitelist.  We can start from the vulnerabilities so far
  discovered.
 
 And here is the *other* fatal problem: a whitelist does not in fact give
 any leverage at all for testing whether there is access to functionality
 outside the whitelist.  (It might be useful if you could enforce the
 whitelist at some sufficiently low level of the language implementation,
 but as a matter of testing, it does nothing for you.)  What you're
 suggesting isn't so much un-fun as un-possible.  Given a maze of twisty
 little subroutines all different, how will you find out if any of them
 contain calls of unwanted functionality?

A jail helps with a lot of this; the remainder is in the normal fact
that bug testing can only demonstrate the presence of bugs and you need
to do formal code proof to check for the absence of bugs.

-- 
  Sam  http://samason.me.uk/
 
 [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.122.5494

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-28 Thread Peter Eisentraut
On fre, 2010-05-28 at 13:03 +0100, Sam Mason wrote:
 That's not normally a problem.  The conventional way would be to place
 the interpreter in its own sandbox, similar to how Chrome has each tab
 running in its own process.  These processes are protected in a way
 so that the code running inside them can't do any harm--e.g. a ptrace
 jail[1].  This is quite a change from existing pl implementations, and
 present a different set of performance/compatibility issues.

Surely a definition of a trusted language that invalidates the existing
trusted languages is not going help resolve the issue.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-28 Thread Andrew Dunstan



Sam Mason wrote:

On Thu, May 27, 2010 at 11:09:26PM -0400, Tom Lane wrote:
  

David Fetter da...@fetter.org writes:


I don't know about a *good* idea, but here's the one I've got.
  
1.  Make a whitelist.  This is what needs to work in order for a

language to be a fully functional trusted PL.
  

Well, I pretty much lose interest right here, because this is already
assuming that every potentially trusted PL is isomorphic in its
capabilities.



That's not normally a problem.  The conventional way would be to place
the interpreter in its own sandbox, similar to how Chrome has each tab
running in its own process.  These processes are protected in a way
so that the code running inside them can't do any harm--e.g. a ptrace
jail[1].  This is quite a change from existing pl implementations, and
present a different set of performance/compatibility issues.

  


I have my own translation of this last sentence.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread Bruce Momjian
Tom Lane wrote:
 Joshua Tolley eggyk...@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  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread David Fetter
On Thu, May 27, 2010 at 11:23:44AM -0400, Bruce Momjian wrote:
 Tom Lane wrote:
  Joshua Tolley eggyk...@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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread Peter Eisentraut
On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
 On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
  Robert Haas robertmh...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread David Fetter
On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote:
 On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
  On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
   Robert Haas robertmh...@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.

That's a great definition from a point of view of understanding by
human beings.  A whitelist system will work better from the point of
automating tests which, while they couldn't conclusively prove that
something was actually this way, could go a long way toward making
sure that PLs didn't regress into untrusted territory.

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread Robert Haas
On Thu, May 27, 2010 at 7:10 PM, David Fetter da...@fetter.org wrote:
 On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote:
 On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
  On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
   Robert Haas robertmh...@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.

 That's a great definition from a point of view of understanding by
 human beings.  A whitelist system will work better from the point of
 automating tests which, while they couldn't conclusively prove that
 something was actually this way, could go a long way toward making
 sure that PLs didn't regress into untrusted territory.

You haven't presented any sort of plan for how such automated testing
would actually work.  Perhaps if you presented the plan first we could
think about how to provide for its needs.  I'm generally of the
opinion that it's not possible to do automated testing for security
vulnerabilities (beyond crash testing, perhaps) but if you have a good
idea let's talk about it.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread David Fetter
On Thu, May 27, 2010 at 09:51:30PM -0400, Robert Haas wrote:
 On Thu, May 27, 2010 at 7:10 PM, David Fetter da...@fetter.org wrote:
  On Fri, May 28, 2010 at 01:03:15AM +0300, Peter Eisentraut wrote:
  On fre, 2010-05-21 at 14:22 -0400, Robert Haas wrote:
   On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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.
 
  That's a great definition from a point of view of understanding by
  human beings.  A whitelist system will work better from the point
  of automating tests which, while they couldn't conclusively prove
  that something was actually this way, could go a long way toward
  making sure that PLs didn't regress into untrusted territory.
 
 You haven't presented any sort of plan for how such automated
 testing would actually work.  Perhaps if you presented the plan
 first we could think about how to provide for its needs.  I'm
 generally of the opinion that it's not possible to do automated
 testing for security vulnerabilities (beyond crash testing, perhaps)
 but if you have a good idea let's talk about it.

I don't know about a *good* idea, but here's the one I've got.

1.  Make a whitelist.  This is what needs to work in order for a
language to be a fully functional trusted PL.

2.  Write tests that check that each thing on the whitelist works as
advertised.  These are language specific.

3.  (the un-fun part) Write tests which attempt to do things not in
the whitelist.  We can start from the vulnerabilities so far
discovered.

4.  Each time a vulnerability is discovered in one language, write
something that tests for it in the other languages.

I get that this isn't going to ensure that the access control is
perfect.  It's more a backstop against regressions of previously
function access controls.

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-27 Thread Tom Lane
David Fetter da...@fetter.org writes:
 I don't know about a *good* idea, but here's the one I've got.

 1.  Make a whitelist.  This is what needs to work in order for a
 language to be a fully functional trusted PL.

Well, I pretty much lose interest right here, because this is already
assuming that every potentially trusted PL is isomorphic in its
capabilities.  If that were so, there'd not be very much point in
supporting multiple PLs.  A good example here is R.  I have no idea
whether PL/R is trusted or trustworthy, but in any case the main point
of supporting that PL is to allow access to the R statistical library.
How does that fit into a whitelist designed for some other language?
It doesn't.

 3.  (the un-fun part) Write tests which attempt to do things not in
 the whitelist.  We can start from the vulnerabilities so far
 discovered.

And here is the *other* fatal problem: a whitelist does not in fact give
any leverage at all for testing whether there is access to functionality
outside the whitelist.  (It might be useful if you could enforce the
whitelist at some sufficiently low level of the language implementation,
but as a matter of testing, it does nothing for you.)  What you're
suggesting isn't so much un-fun as un-possible.  Given a maze of twisty
little subroutines all different, how will you find out if any of them
contain calls of unwanted functionality?

If you think you can do something with this, go for it, but don't
expect me to spend any of my time on it.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-24 Thread Jan Wieck

On 5/23/2010 11:19 PM, Andrew Dunstan wrote:


Jan Wieck wrote:


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.


How is loading code which might do any of those things different 
from writing a stored procedure, that accesses data, a careless 
superuser left in a global variable? Remember, the code of a PL 
function is open source - like in everyone can select from 
pg_proc. You really don't expect anyone to scan for your global 
variables just because they can write functions in the same language?




Well, that threat arises from the unsafe actions of the careless 
superuser. And we could at least ameliorate it by providing a per role 
data stash, at very little cost, as I mentioned. It's not like we don't 
know about such threats, and I'm certainly not pretending they don't 
exist. The 9.0 PL/Perl docs say:


The %_SHARED variable and other global state within the language is
public data, available to all PL/Perl functions within a session.
Use with care, especially in situations that involve use of multiple
roles or SECURITY DEFINER functions.


But the threats I was referring to arise if the language allows them to, 
without any requirement for unsafe actions by another user. Protecting 
against those is the essence of trustedness in my mind at least.


I can agree with that.


Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-24 Thread Greg Sabino Mullane

-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 g...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Ron Mayer
Tom Lane wrote:
 Robert Haas robertmh...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Jan Wieck

On 5/23/2010 6:14 PM, Ron Mayer wrote:

Tom Lane wrote:

Robert Haas robertmh...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Andrew Dunstan



Jan Wieck wrote:

On 5/23/2010 6:14 PM, Ron Mayer wrote:

Tom Lane wrote:

Robert Haas robertmh...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Craig Ringer

On 21/05/10 23:55, Josh Berkus wrote:

So, here's a working definition:

1) cannot directly read or write files on the server.


It must also prevent PL-user-level access to file descriptors already 
open by the backend. That's implicitly covered in the above, but should 
probably be explicit.



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


5) Cannot dynamically load shared libraries from user-supplied locations

(eg in Python, 'import' of a module that had a .so component would be 
blocked unless it was in the core module path)



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.


Like:

5) Has no way to directly access backend memory, ie doesn't have 
PL-user-accessible pointers or user access to any C-level calls that 
take/return them. Data structures containing pointers must be opaque to 
the PL user.


The idea being that if you have no access to C APIs that work with 
pointers to memory, and you can't use files (/dev/mem, /proc/self/mem, 
etc), you can't work with backend memory directly.


--
Craig Ringer

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Jan Wieck

On 5/23/2010 10:04 PM, Andrew Dunstan wrote:


Jan Wieck wrote:

On 5/23/2010 6:14 PM, Ron Mayer wrote:

Tom Lane wrote:

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


How is loading code which might do any of those things different from 
writing a stored procedure, that accesses data, a careless superuser 
left in a global variable? Remember, the code of a PL function is open 
source - like in everyone can select from pg_proc. You really don't 
expect anyone to scan for your global variables just because they can 
write functions in the same language?



Jan

--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Craig Ringer

On 22/05/10 02:12, Robert Haas wrote:

On Fri, May 21, 2010 at 1:58 PM, David Fetterda...@fetter.org  wrote:

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

* David Fetter (da...@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?


Personally, I don't think a PL should be trusted unless it _does_ define 
a whitelist of operations. Experience in the wider world has shown that 
this is the only approach that works. Regression testing to make sure 
all possible approaches to access unsafe features are blocked is doomed 
to have holes where there's another approach that hasn't been thought of 
yet.


Perl's new approach is whitelist based. Python restricted mode failed 
not least because it was a blacklist and people kept on finding ways 
around it. Lua and JavaScript are great examples of whitelist 
approaches, where the language just doesn't expose features that're 
dangerous - in fact, the core language doesn't even *have* those 
features. PL/PgSQL is the same, and works well as a trusted language for 
that reason.


Java's SecurityManager is whitelist based (allowed classes, allowed 
operations), and has proved very secure.


--
Craig Ringer

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-23 Thread Andrew Dunstan



Jan Wieck wrote:


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.


How is loading code which might do any of those things different 
from writing a stored procedure, that accesses data, a careless 
superuser left in a global variable? Remember, the code of a PL 
function is open source - like in everyone can select from 
pg_proc. You really don't expect anyone to scan for your global 
variables just because they can write functions in the same language?




Well, that threat arises from the unsafe actions of the careless 
superuser. And we could at least ameliorate it by providing a per role 
data stash, at very little cost, as I mentioned. It's not like we don't 
know about such threats, and I'm certainly not pretending they don't 
exist. The 9.0 PL/Perl docs say:


   The %_SHARED variable and other global state within the language is
   public data, available to all PL/Perl functions within a session.
   Use with care, especially in situations that involve use of multiple
   roles or SECURITY DEFINER functions.


But the threats I was referring to arise if the language allows them to, 
without any requirement for unsafe actions by another user. Protecting 
against those is the essence of trustedness in my mind at least.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-22 Thread Alexey Klyukin
On Fri, May 21, 2010 at 7:25 PM, Magnus Hagander mag...@hagander.net wrote:
 On Fri, May 21, 2010 at 12:22 PM, David Fetter da...@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 j...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-22 Thread Cédric Villemain
2010/5/21 Jan Wieck janwi...@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@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-22 Thread Robert Haas
On Sat, May 22, 2010 at 4:53 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
 2010/5/21 Jan Wieck janwi...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Specification for Trusted PLs?

2010-05-21 Thread David Fetter
Folks,

I feel dumb.

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

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

Cheers,
David.
-- 
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Stephen Frost
* David Fetter (da...@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


signature.asc
Description: Digital signature


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Peter Geoghegan
 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Tom Lane
Peter Geoghegan peter.geoghega...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Josh Berkus

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Magnus Hagander
On Fri, May 21, 2010 at 11:55 AM, Josh Berkus j...@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/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Josh Berkus

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

On Fri, May 21, 2010 at 11:55 AM, Josh Berkusj...@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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread David Fetter
On Fri, May 21, 2010 at 11:57:33AM -0400, Magnus Hagander wrote:
 On Fri, May 21, 2010 at 11:55 AM, Josh Berkus j...@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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Stephen Frost
* David Fetter (da...@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


signature.asc
Description: Digital signature


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Magnus Hagander
On Fri, May 21, 2010 at 12:22 PM, David Fetter da...@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 j...@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/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread David Fetter
On Fri, May 21, 2010 at 12:26:24PM -0400, Stephen Frost wrote:
 * David Fetter (da...@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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Stephen Frost
* David Fetter (da...@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


signature.asc
Description: Digital signature


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread David Fetter
On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
 * David Fetter (da...@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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Florian Pflug
On May 21, 2010, at 18:26 , Stephen Frost wrote:
 * David Fetter (da...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Stephen Frost
* David Fetter (da...@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


signature.asc
Description: Digital signature


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Tom Lane
David Fetter da...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Robert Haas
On Fri, May 21, 2010 at 1:58 PM, David Fetter da...@fetter.org wrote:
 On Fri, May 21, 2010 at 01:45:45PM -0400, Stephen Frost wrote:
 * David Fetter (da...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Tom Lane
Robert Haas robertmh...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Robert Haas
On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Greg Sabino Mullane

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



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Stephen Frost
* Robert Haas (robertmh...@gmail.com) wrote:
 So... can we get back to coming up with a reasonable
 definition, and 

Guess I'm wondering if we could steal such a definition from one of the
languages we allow as trusted already..  Just a thought.  I certainly
think we should make sure that we document how untrusted languages are
handled from the PG point of view (eg: can't change ownership).

 if somebody wants to write some regression tests, all
 the better?

I certainly am fine with that to the extent that they want to work on
that instead of hacking PG..  Guess I just don't think it should be a
priority for us to come up with a signifigant regression suite for
pieces that are supposedly being externally managed.

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Tom Lane
Greg Sabino Mullane g...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread David Fetter
On Fri, May 21, 2010 at 03:15:27PM -0400, Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread David Fetter
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 robertmh...@gmail.com writes:
   On Fri, May 21, 2010 at 2:21 PM, Tom Lane t...@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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Joshua Tolley
On Fri, May 21, 2010 at 1:36 PM, David Fetter da...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Tom Lane
Joshua Tolley eggyk...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Jonathan Leto
Howdy,

On Fri, May 21, 2010 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@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
jonat...@leto.net
http://leto.net

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Joshua Tolley
On Fri, May 21, 2010 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Joshua Tolley eggyk...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Specification for Trusted PLs?

2010-05-21 Thread Jan Wieck
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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers