Re: plperl Safe restrictions
Re: [PATCHES] plperl Safe restrictions
От:
John Hansen <john@geeknet.com.au>
Дата:
> Applied, with changes to allow srand and disallow sprintf, as per > subsequent discussion. How about allowing: use utf8; use locale; ? Kind Regards, John
Re: [PATCHES] plperl Safe restrictions
От:
John Hansen <john@geeknet.com.au>
Дата:
> I think it is *way* too late in the dev cycle to be proposing this. > Maybe it should be a TODO item - I at least don't have time even to > think about the implications os using these pragmas. The effect of the > first is achievable via an environment setting, I believe. > > If you need these badly enough, use plperlu where there are no > restrictions to overcome - the big problem is that 'use anything' > requires that we enable the 'require' op, and that is certainly not > going to happen without a great deal of thought. Fair enough, was just a suggestion as they seem obviously useful, even to the non-superuser plperl programmer. TODO item would suffice :) ... John
Re: [PATCHES] plperl Safe restrictions
От:
"Andrew Dunstan" <andrew@dunslane.net>
Дата:
Bruce Momjian said: > > Uh, what was the TODO here? I forgot. > > John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted code. If there's a TODO it would be to investigate the possibility, as I am very far from certain that there is a simple way to do it safely right now. Maybe when we get plperl using GUC settings and running some interpreter initialisation it could be done. These are things on my agenda. cheers andrew --------------------------------------------------------------------------- > > John Hansen wrote: >> > I think it is *way* too late in the dev cycle to be proposing this. >> > Maybe it should be a TODO item - I at least don't have time even to >> > think about the implications os using these pragmas. The effect of >> > the first is achievable via an environment setting, I believe. >> > >> > If you need these badly enough, use plperlu where there are no >> > restrictions to overcome - the big problem is that 'use anything' >> > requires that we enable the 'require' op, and that is certainly not >> > going to happen without a great deal of thought. >> >> Fair enough, was just a suggestion as they seem obviously useful, even >> to the non-superuser plperl programmer. >> >> TODO item would suffice :) >> >> ... John
Re: [PATCHES] plperl Safe restrictions
От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Bruce Momjian writes: > Uh, what was the TODO here? I forgot. I think we already did what we decided was safe there. regards, tom lane
Re: [PATCHES] plperl Safe restrictions
От:
Bruce Momjian <pgman@candle.pha.pa.us>
Дата:
Uh, what was the TODO here? I forgot. --------------------------------------------------------------------------- John Hansen wrote: > > I think it is *way* too late in the dev cycle to be proposing this. > > Maybe it should be a TODO item - I at least don't have time even to > > think about the implications os using these pragmas. The effect of the > > first is achievable via an environment setting, I believe. > > > > If you need these badly enough, use plperlu where there are no > > restrictions to overcome - the big problem is that 'use anything' > > requires that we enable the 'require' op, and that is certainly not > > going to happen without a great deal of thought. > > Fair enough, was just a suggestion as they seem obviously useful, even > to the non-superuser plperl programmer. > > TODO item would suffice :) > > ... John > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Re: [PATCHES] plperl Safe restrictions
От:
Tom Lane <tgl@sss.pgh.pa.us>
Дата:
Andrew Dunstan writes: > It has just been brought to my attention that we are being very > restrictive about what we allow to be done in trusted plperl. > ... > OK, based on this and some further thought, I have prepared the attached > patch which does the right thing, I think, both in terms of what we > allow and what we don't. Applied, with changes to allow srand and disallow sprintf, as per subsequent discussion. regards, tom lane
Re: plperl Safe restrictions
От:
Andrew Dunstan <andrew@dunslane.net>
Дата:
David Helgason wrote:
> On 14. okt 2004, at 21:09, Andrew Dunstan wrote:
>
>> It has just been brought to my attention that we are being very
>> restrictive about what we allow to be done in trusted plperl.
>> Basically we allow the :default and :base_math set of operations (run
>> perldoc Opcode or see
>> http://www.perldoc.com/perl5.8.0/lib/Opcode.html for details of what
>> these mean). In particular, we do not allow calls to perl's builtin
>> sort, which is unpleasant, and on reviewing the list it seems to me
>> we could quite reasonably allow access to pack and unpack also. bless
>> and sprintf are also likely candidates for inclusion - I have not
>> finished reviewing the list, and would welcome advice from perl gurus
>> on this.
>
>
> pack and unpack are unfortunately not safe. Very useful, but they
> allow write/read access to random memory. It's really a shame perl
> doesn't have a pragma to make them safe or have safe versions of them.
>
> Bless should be OK, unless sensitive objects are provided to the
> procedures.
>
> A postgres question I don't know the answer to is whether allowing the
> user to trigger a segfault is a security problem. If it isn't, several
> opcodes may probably be allowed, including sort and sprintf. If it is,
> well, you need only follow the perl5-porters list to know that there's
> banal perl structures are continuously being found that will segfault
> perl, some at compile time, other at runtime.
OK, based on this and some further thought, I have prepared the attached
patch which does the right thing, I think, both in terms of what we
allow and what we don't.
First, we tighten security by disallowing access to srand and IO
functions on existing filehandles (other IO ops are already disallowed).
The we relax the restrictions by allowing access to perl's sort, sprintf
and time routines. I decided against pack/unpack based on the above, and
also decided that I couldn't think of any case where bless would have
any practical use - although that might change later. I'm trying to keep
changes minimal here. I don't believe that "time" carries any
significant security implications, and I think the dangers from "sort"
and "sprintf" are not so great as to disallow them. They might cause a
SEGV in a pathological case, but that doesn't give the user access to
the machine - if they can login to postgres they can probably mount any
number of DOS attacks anyway.
To answer David's question, the man says this about trusted functions:
"the TRUSTED flag should only be given for languages that do not allow
access to database server internals or the file system". I think the
changes I propose fit in with that statement.
The patch also does some other inconsequential tidying of overlong
lines, and removes some unnecessary ops in the unsafe case. These are
basically cosmetic - the only significant part is replacing this:
$PLContainer->permit(':base_math');
with this:
$PLContainer->permit(qw[:base_math !:base_io !srand sort sprintf time]);
I have tested and it appears to do the right thing, both for the things
excluded and those included.
cheers
andrew
Index: src/pl/plperl/plperl.c
===================================================================
RCS file: /home/cvsmirror/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.54
diff -c -r1.54 plperl.c
*** src/pl/plperl/plperl.c 7 Oct 2004 19:01:09 -0000 1.54
--- src/pl/plperl/plperl.c 15 Oct 2004 14:48:18 -0000
***************
*** 250,266 ****
static char *safe_ok =
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');"
! "$PLContainer->permit_only(':default');$PLContainer->permit(':base_math');"
! "$PLContainer->share(qw[&elog &spi_exec_query &DEBUG &LOG &INFO &NOTICE &WARNING &ERROR %SHARED ]);"
"sub ::mksafefunc { return $PLContainer->reval(qq[sub { $_[0] $_[1]}]); }"
;
static char *safe_bad =
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');"
! "$PLContainer->permit_only(':default');$PLContainer->permit(':base_math');"
! "$PLContainer->share(qw[&elog &DEBUG &LOG &INFO &NOTICE &WARNING &ERROR %SHARED ]);"
"sub ::mksafefunc { return $PLContainer->reval(qq[sub { "
! "elog(ERROR,'trusted perl functions disabled - please upgrade perl Safe module to at least 2.09');}]); }"
;
SV *res;
--- 250,269 ----
static char *safe_ok =
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');"
! "$PLContainer->permit_only(':default');"
! "$PLContainer->permit(qw[:base_math !:base_io !srand sort sprintf time]);"
! "$PLContainer->share(qw[&elog &spi_exec_query &DEBUG &LOG "
! "&INFO &NOTICE &WARNING &ERROR %SHARED ]);"
"sub ::mksafefunc { return $PLContainer->reval(qq[sub { $_[0] $_[1]}]); }"
;
static char *safe_bad =
"use vars qw($PLContainer); $PLContainer = new Safe('PLPerl');"
! "$PLContainer->permit_only(':default');"
! "$PLContainer->share(qw[&elog &ERROR ]);"
"sub ::mksafefunc { return $PLContainer->reval(qq[sub { "
! "elog(ERROR,'trusted perl functions disabled - "
! "please upgrade perl Safe module to at least 2.09');}]); }"
;
SV *res;
Re: [PATCHES] plperl Safe restrictions
От:
Andrew Dunstan <andrew@dunslane.net>
Дата:
Bruce Momjian wrote:
>Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
>It will be applied as soon as one of the PostgreSQL committers reviews
>and approves it.
>
>---------------------------------------------------------------------------
>
>
>Andrew Dunstan wrote:
>
>
>>...
>>
>>The patch also does some other inconsequential tidying of overlong
>>lines, and removes some unnecessary ops in the unsafe case. These are
>>basically cosmetic - the only significant part is replacing this:
>>
>> $PLContainer->permit(':base_math');
>>
>>with this:
>>
>> $PLContainer->permit(qw[:base_math !:base_io !srand sort sprintf time]);
>>
>>
>>
>
As per previous discussions, please remove "!srand" and "sprintf"
if/when applying.
cheers
andrew
Re: [PATCHES] plperl Safe restrictions
От:
Andrew Dunstan <andrew@dunslane.net>
Дата:
John Hansen wrote: >>Applied, with changes to allow srand and disallow sprintf, as per >>subsequent discussion. >> >> > >How about allowing: > >use utf8; >use locale; > >? > > > > I think it is *way* too late in the dev cycle to be proposing this. Maybe it should be a TODO item - I at least don't have time even to think about the implications os using these pragmas. The effect of the first is achievable via an environment setting, I believe. If you need these badly enough, use plperlu where there are no restrictions to overcome - the big problem is that 'use anything' requires that we enable the 'require' op, and that is certainly not going to happen without a great deal of thought. cheers andrew
