plperl _init settings
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
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
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
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
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.
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
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.
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
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.
Attachments:
plperl-safe-225-rand.patchtext/x-patch; charset=us-asciiDownload
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index c000463..0cc59c5 100644
*** a/doc/src/sgml/plperl.sgml
--- b/doc/src/sgml/plperl.sgml
*************** $$ LANGUAGE plperl;
*** 856,862 ****
operations that are restricted are those that interact with the
environment. This includes file handle operations,
<literal>require</literal>, and <literal>use</literal> (for
! external modules). There is no way 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. Thus, any unprivileged database user can
--- 856,864 ----
operations that are restricted are those that interact with the
environment. This includes file handle operations,
<literal>require</literal>, and <literal>use</literal> (for
! external modules). To the extent it is prevented by the Perl
! <ulink url="http://search.cpan.org/perldoc?Safe">Safe</ulink> 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. Thus, any unprivileged database user can
diff --git a/src/pl/plperl/plc_safe_ok.pl b/src/pl/plperl/plc_safe_ok.pl
index ee2e33f..873143f 100644
*** a/src/pl/plperl/plc_safe_ok.pl
--- b/src/pl/plperl/plc_safe_ok.pl
*************** if (not our $_init++) {
*** 52,58 ****
# --- create and initialize a new container ---
$SafeClass ||= 'Safe';
! $PLContainer = $SafeClass->new('PostgreSQL::InServer::safe_container');
$PLContainer->permit_only(':default');
$PLContainer->permit(qw[:base_math !:base_io sort time require]);
--- 52,64 ----
# --- create and initialize a new container ---
$SafeClass ||= 'Safe';
! # Give the container a random name to complicate an attack that needs the name
! # (Iff perl is loaded via shared_preload_libraries and perl uses the same
! # random function as postgres then perl's own seed function would have already
! # been called and an attacker could call the postgres setseed() before first
! # use of plperl to control the rand result. Even so, we try to make life hard.)
! # There's no known exploit based on this but it's cheap and wise.
! $PLContainer = $SafeClass->new('PostgreSQL::InServer::safe'.int(rand(time+$^T+$!)));
$PLContainer->permit_only(':default');
$PLContainer->permit(qw[:base_math !:base_io sort time require]);
*************** sub safe_eval {
*** 91,95 ****
}
sub mksafefunc {
! ! return safe_eval(PostgreSQL::InServer::mkfuncsrc(@_));
}
--- 97,101 ----
}
sub mksafefunc {
! return safe_eval(PostgreSQL::InServer::mkfuncsrc(@_));
}
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index 956eddb..a834063 100644
*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
*************** plperl_trusted_init(void)
*** 691,702 ****
safe_version_x100 = (int) (SvNV(safe_version_sv) * 100);
/*
! * Reject too-old versions of Safe and some others: 2.20:
! * http://rt.perl.org/rt3/Ticket/Display.html?id=72068 2.21:
! * http://rt.perl.org/rt3/Ticket/Display.html?id=72700
*/
! if (safe_version_x100 < 209 || safe_version_x100 == 220 ||
! safe_version_x100 == 221)
{
/* not safe, so disallow all trusted funcs */
eval_pv(PLC_SAFE_BAD, FALSE);
--- 691,699 ----
safe_version_x100 = (int) (SvNV(safe_version_sv) * 100);
/*
! * Reject too-old versions of Safe
*/
! if (safe_version_x100 < 225)
{
/* not safe, so disallow all trusted funcs */
eval_pv(PLC_SAFE_BAD, FALSE);
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
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
"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
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.
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
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/
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?
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
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.