Re: [PATCHES] plperl Safe restrictions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] plperl Safe restrictions
Date: 2004-11-11 17:07:35
Message-ID: 200411111707.iABH7Zn28656@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-11-11 17:12:58 Re: plperl Safe restrictions
Previous Message Patrick B Kelly 2004-11-11 16:53:00 Re: multiline CSV fields

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-11-11 17:12:58 Re: plperl Safe restrictions
Previous Message Bruce Momjian 2004-11-11 17:06:50 Re: pg_restore - added documentation