Re: [HACKERS] Safe security
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.
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,
literalrequire/literal, and literaluse/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,
literalrequire/literal, and literaluse/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);
--
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] Safe security
Tim Bunce tim.bu...@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 -- 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] Safe security
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 -- 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] Safe security
David E. Wheeler da...@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 -- 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] Safe security
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote: Tim Bunce tim.bu...@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. -- 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] Safe security
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 -- 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] Safe security
2010/3/8 David E. Wheeler da...@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/ -- 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] Safe security
On Mon, Mar 8, 2010 at 09:03, Tom Lane t...@sss.pgh.pa.us wrote: Tim Bunce tim.bu...@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? -- 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] Safe security
Alex Hunsaker bada...@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 -- 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] Safe security
On Mon, Mar 8, 2010 at 10:14, Tom Lane t...@sss.pgh.pa.us wrote: David E. Wheeler da...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Safe security (was: plperl _init settings)
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. -- 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] Safe security
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 -- 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] Safe security
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. -- 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] Safe security
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
