Horton
Menu

Thread

  1. plperl _init settings

    Andrew Dunstan <andrew@dunslane.net> — 2010-03-03T00:33:47Z

    There appears to be some significant misunderstanding of what can be 
done effectively using the various *_init settings for plperl.

In particular, some people have got an expectation that modules loaded 
in plperl.on_init will thereby be available for use in trusted plperl.

I propose to add the following note to the docs:

    Preloading modules using plperl.on_init does not make them available
    for use by plperl. External perl modules can only be used in plperlu.

Comments?

cheers

andrew

  2. Re: plperl _init settings

    David E. Wheeler <david@kineticode.com> — 2010-03-03T01:12:40Z

    On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote:

> I propose to add the following note to the docs:
> 
>   Preloading modules using plperl.on_init does not make them available
>   for use by plperl. External perl modules can only be used in plperlu.

Perhaps add a note that some other interface to allow preloaded modules to also be available to plperl may be provided in the future.

Best,

David

  3. Re: plperl _init settings

    Andrew Dunstan <andrew@dunslane.net> — 2010-03-03T02:00:03Z

    
David E. Wheeler wrote:
> On Mar 2, 2010, at 4:33 PM, Andrew Dunstan wrote:
>
>   
>> I propose to add the following note to the docs:
>>
>>   Preloading modules using plperl.on_init does not make them available
>>   for use by plperl. External perl modules can only be used in plperlu.
>>     
>
> Perhaps add a note that some other interface to allow preloaded modules to also be available to plperl may be provided in the future.
>
>
>   

No, that's far from a done deal.

cheers

andrew

  4. Re: plperl _init settings

    David E. Wheeler <david@kineticode.com> — 2010-03-03T03:01:34Z

    On Mar 2, 2010, at 6:00 PM, Andrew Dunstan wrote:

>> Perhaps add a note that some other interface to allow preloaded modules to also be available to plperl may be provided in the future. 
> 
> No, that's far from a done deal.

Hence the “may.” But either way.

David

  5. Safe security (was: plperl _init settings)

    Tim Bunce <tim.bunce@pobox.com> — 2010-03-03T16:15:58Z

    On Tue, Mar 02, 2010 at 07:33:47PM -0500, Andrew Dunstan wrote:
> 
> There appears to be some significant misunderstanding of what can be
> done effectively using the various *_init settings for plperl.
> 
> In particular, some people have got an expectation that modules
> loaded in plperl.on_init will thereby be available for use in
> trusted plperl.
> 
> I propose to add the following note to the docs:
> 
>    Preloading modules using plperl.on_init does not make them available
>    for use by plperl. External perl modules can only be used in plperlu.
> 
> Comments?

Sounds good.

FYI the maintainers of Safe are aware of (at least) two exploits which
are being considered at the moment.

You might want to soften the wording in
http://developer.postgresql.org/pgdocs/postgres/plperl-trusted.html
"There is no way to ..." is a stronger statement than can be justified.

The docs for Safe http://search.cpan.org/~rgarcia/Safe-2.23/Safe.pm#WARNING
say "The authors make no warranty, implied or otherwise, about the
suitability of this software for safety or security purposes".

Tim.

  6. Re: Safe security

    Andrew Dunstan <andrew@dunslane.net> — 2010-03-03T16:33:37Z

    
Tim Bunce wrote:
> FYI the maintainers of Safe are aware of (at least) two exploits which
> are being considered at the moment.
>
> You might want to soften the wording in
> http://developer.postgresql.org/pgdocs/postgres/plperl-trusted.html
> "There is no way to ..." is a stronger statement than can be justified.
>   

Perhaps "There is no way provided to ...".
> The docs for Safe http://search.cpan.org/~rgarcia/Safe-2.23/Safe.pm#WARNING
> say "The authors make no warranty, implied or otherwise, about the
> suitability of this software for safety or security purposes".
>
>
>   

Well, we could put in similar weasel words I guess. But after all, 
Safe's very purpose is to provide a restricted execution environment, no?

cheers

andrew

  7. Re: Safe security

    Joshua D. Drake <jd@commandprompt.com> — 2010-03-03T16:45:47Z

    On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:

> >   
> 
> Well, we could put in similar weasel words I guess. But after all, 
> Safe's very purpose is to provide a restricted execution environment, no?

We already do, in our license.

Joshua D. Drake


> 
> cheers
> 
> andrew
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.

  8. Re: Safe security

    Andrew Dunstan <andrew@dunslane.net> — 2010-03-04T00:01:56Z

    
Joshua D. Drake wrote:
> On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
>
>   
>>>   
>>>       
>> Well, we could put in similar weasel words I guess. But after all, 
>> Safe's very purpose is to provide a restricted execution environment, no?
>>     
>
> We already do, in our license.
>
>
>   


True. I think the weasel formula I prefer here is a bit different. It 
might be reasonable to say something along the lines of:

    To the extent it is prevented by the Perl Safe module, there is no
    way provided to access internals of the database server process or
    to gain OS-level access with the permissions of the server process,
    as a C function can do.


cheers

andrew

  9. Re: Safe security

    Tim Bunce <tim.bunce@pobox.com> — 2010-03-08T14:37:20Z

    On Wed, Mar 03, 2010 at 07:01:56PM -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
> >
> >>Well, we could put in similar weasel words I guess. But after
> >>all, Safe's very purpose is to provide a restricted execution
> >>environment, no?
> >
> >We already do, in our license.
> 
> True. I think the weasel formula I prefer here is a bit different.
> It might be reasonable to say something along the lines of:
> 
>    To the extent it is prevented by the Perl Safe module, there is no
>    way provided to access internals of the database server process or
>    to gain OS-level access with the permissions of the server process,
>    as a C function can do.

Here's a patch that:
1. adds wording like that to the docs.
2. randomises the container package name (a simple and sound security measure).
3. requires Safe 2.25 (which has assorted fixes, including security).
4. removed a harmless but suprious exclamation mark from the source.

Tim.

  10. Re: Safe security

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-08T16:03:27Z

    Tim Bunce <Tim.Bunce@pobox.com> writes:
> Here's a patch that:
> 1. adds wording like that to the docs.
> 2. randomises the container package name (a simple and sound security measure).
> 3. requires Safe 2.25 (which has assorted fixes, including security).
> 4. removed a harmless but suprious exclamation mark from the source.

#3 is still an absolute nonstarter, especially for a patch that we'd
wish to backpatch.

			regards, tom lane

  11. Re: Safe security

    David E. Wheeler <david@kineticode.com> — 2010-03-08T16:55:29Z

    On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:

> #3 is still an absolute nonstarter, especially for a patch that we'd
> wish to backpatch.

You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.

Best,

David

  12. Re: Safe security

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-08T17:14:14Z

    "David E. Wheeler" <david@kineticode.com> writes:
> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
>> #3 is still an absolute nonstarter, especially for a patch that we'd
>> wish to backpatch.

> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.

If those aren't versions that are likely to be in wide use, no objection
to that.  I'm just concerned about arbitrarily breaking existing
installations.  I note that Fedora 11 and OS X 10.6.2 are providing Safe
2.12, which means the proposed patch would break plperl on every machine
I have, without easy recourse --- I am not likely to install a private
version of Safe under either OS, and I doubt many other PG users would
wish to either.  The net effect would be to prevent PG users from
upgrading until the OS vendors get around to issuing new versions,
which is not helpful.  Particularly if the vendor chooses to back-patch
Safe security fixes without bumping the visible version number, as is
not unlikely for Red Hat in particular.

			regards, tom lane

  13. Re: Safe security

    Tim Bunce <tim.bunce@pobox.com> — 2010-03-08T17:32:03Z

    On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
> Tim Bunce <Tim.Bunce@pobox.com> writes:
> > Here's a patch that:
> > 1. adds wording like that to the docs.
> > 2. randomises the container package name (a simple and sound security measure).
> > 3. requires Safe 2.25 (which has assorted fixes, including security).
> > 4. removed a harmless but suprious exclamation mark from the source.
> 
> #3 is still an absolute nonstarter, especially for a patch that we'd
> wish to backpatch.

This is a patch for 9.0. Backpatching is a separate issue.

I think Safe 2.25 should be required, but I'll let whoever applies the
patch tweak/delete that hunk as desired.

Tim.

  14. Re: Safe security

    David E. Wheeler <david@kineticode.com> — 2010-03-08T17:41:35Z

    On Mar 8, 2010, at 9:14 AM, Tom Lane wrote:

> If those aren't versions that are likely to be in wide use, no objection
> to that.

Yes, those are a series of releases in the last couple of months that had one level of brokenness or another I'm going to test 2.25 today.

> I'm just concerned about arbitrarily breaking existing
> installations. I note that Fedora 11 and OS X 10.6.2 are providing Safe
> 2.12, which means the proposed patch would break plperl on every machine
> I have, without easy recourse --- I am not likely to install a private
> version of Safe under either OS, and I doubt many other PG users would
> wish to either.  The net effect would be to prevent PG users from
> upgrading until the OS vendors get around to issuing new versions,
> which is not helpful.

Agreed, older ones should be allowed; the Perl community should recommend that everyone upgrade to get improved security, but it shouldn't be required.

> Particularly if the vendor chooses to back-patch
> Safe security fixes without bumping the visible version number, as is
> not unlikely for Red Hat in particular.

This is why I hate packaging systems. Frankly, Red Hat's Perl has been consistently broken for close to a decade, mainly because of patching practices such as this.

Best,

David

  15. Re: Safe security

    Magnus Hagander <magnus@hagander.net> — 2010-03-08T17:55:14Z

    2010/3/8 David E. Wheeler <david@kineticode.com>:
>> Particularly if the vendor chooses to back-patch
>> Safe security fixes without bumping the visible version number, as is
>> not unlikely for Red Hat in particular.
>
> This is why I hate packaging systems. Frankly, Red Hat's Perl has been consistently broken for close to a decade, mainly because of patching practices such as this.

Goes both way - it's the main reason I hate CPAN, and I know many
sysadmins who hold just that position. (to be clear: the lack of
back-branch management on CPAN is what sucks)

But we're not arguing that. We know it's a situation out there, and we
jus thave to deal with it.


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

  16. Re: Safe security

    Alex Hunsaker <badalex@gmail.com> — 2010-03-08T18:11:07Z

    On Mon, Mar 8, 2010 at 09:03, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Tim Bunce <Tim.Bunce@pobox.com> writes:
>> 3. requires Safe 2.25 (which has assorted fixes, including security).

> #3 is still an absolute nonstarter, especially for a patch that we'd
> wish to backpatch.

FWIW I think its a given you probably always want the latest version
of X or Y.  I mean what happens when Safe 2.26 comes out and fixes
more issues?  We blacklist 2.25?  Seems like a PITA.  Why not just
have something in the docs about keeping your stuff up2date?

That being said I would be in favor of at least saying "Hey! your
using a known broken version of Safe".  Maybe something like the below
at pl_perl init time?  (That is instead of requiring >v2.25 just
complain about older versions)

elog(WARNING, "Safe versions before 2.25 have known issues.  Please
consider upgrading.");

Thoughts?

  17. Re: Safe security

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-08T20:16:04Z

    Alex Hunsaker <badalex@gmail.com> writes:
> That being said I would be in favor of at least saying "Hey! your
> using a known broken version of Safe".  Maybe something like the below
> at pl_perl init time?  (That is instead of requiring >v2.25 just
> complain about older versions)

> elog(WARNING, "Safe versions before 2.25 have known issues.  Please
> consider upgrading.");

We're in the service of providing a tool, not a nanny.

			regards, tom lane

  18. Re: Safe security

    Alex Hunsaker <badalex@gmail.com> — 2010-03-08T20:54:33Z

    On Mon, Mar 8, 2010 at 10:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
>> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
>>> #3 is still an absolute nonstarter, especially for a patch that we'd
>>> wish to backpatch.
>
>> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
>
> If those aren't versions that are likely to be in wide use, no objection
> to that.  I'm just concerned about arbitrarily breaking existing
> installations.

Here are a few version numbers for released perls:
perl | safe version
5.8.8   | 2.12
5.8.9   | 2.16
5.10.0 | 2.12
5.10.1 | 2.18

5.12 looks like it will release with > 2.25, 5.10.2 if it ever gets
released is currently at 2.18, 5.8.10 does not even seem to be on the
horizon.

So unless you installed a private version or your distro is providing
updates (I looked at: arch, debian, fedora and openbsd.  And they
don't seem to.) it seems unlikely to see >2.18 in the wild.