Re: [PATCHES] plperl Safe restrictions

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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073