Re: [PATCHES] plperl Safe restrictions
Bruce Momjian
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:
>
>
> 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
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
--
Bruce Momjian | http://candle.pha.pa.us
pg...@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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
John Hansen
> subsequent discussion.
How about allowing:
use utf8;
use locale;
?
Kind Regards,
John
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
Andrew Dunstan
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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings