Skip site navigation (1) Skip section navigation (2)

Fix for PlPython trust problems

From: Kevin Jacobs <jacobs(at)penguin(dot)theopalgroup(dot)com>
To: <pgsql-patches(at)postgresql(dot)org>
Subject: Fix for PlPython trust problems
Date: 2001-11-15 14:56:42
Message-ID: Pine.LNX.4.33.0111150933450.31242-200000@penguin.theopalgroup.com (view raw or flat)
Thread:
Lists: pgsql-patches
Hello,

Attached is a patch for PlPython from version 7.2b2 that addresses all
'trust' problem that were discovered during my security audit of the module.
I've gotten some positive feedback on this patch and have tested it myself
in several fairly demanding applications for several days.  This patch
primarily removes all read-only filesystem access that is made available by
the default configuration of the restricted execution environment used in
PlPython.  Virtually all operating system and filesystem write-access were
already prohibited.

Here are the details of what I have added or changed:

	1) Overrode the default RExec (restricted execution object) 'r_open'
	   function, which controls all file-open calls.  Previously, it
	   would allow read-only access and throw an exception, otherwise.
	   I have added a new 'r_open' handler that unconditionally throws
	   an exception instead of allowing any file access from within the
	   Python interpreter.

	2) Removed access to previously available read-only POSIX system
	   functions (including fstat, listdir, lstat, readlink, stat,
	   times, uname, getpid, getppid, getcwd, getuid, getgid, geteuid,
	   getegid).  Note that exec, system, unlink, etc. were already
	   excluded.

	3) Tweaked which elements of the 'sys' module are available to hide
	   path and system configuration information about the Python
	   installation.  This information is unnecessary in an embedded
	   environment and may have given an attacker useful system
	   information.

	4) Re-arranged the RExec initialization for clarity, improved
	   performance and extensibility.  Instead of configuring instances
	   of the RExec class each time we instantiate it, now we simply
	   alter the class definition so that all instances share the
	   settings automatically.

	5) Cleaned up static declarations a bit.

	6) Added test cases to exercise the improved sandbox.

	7) Added a few extra modules to the importable list since they are
	   generally regarded to be safe and useful.

I've tested this patch with Python 2.0, 2.1 and 2.2b1.  I have no idea if it
previously worked with 1.5.x, or if it will now.

Tom Lane has expressed concern about shipping PlPython as a trusted language
in PostgreSQL 7.2 in light of these and other possibly undetected security
holes.  I believe that my audit has covered all the bases, though I welcome
comments, scrutiny and review.  So long as the Python installation has not
been subverted, I believe that this patch makes PlPython fairly safe.

Regards,
-Kevin Jacobs

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs(at)theopalgroup(dot)com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com

Attachment: diff-plpython
Description: text/plain (12.2 KB)

Responses

pgsql-patches by date

Next:From: Zeugswetter Andreas SB SDDate: 2001-11-15 15:44:07
Subject: Re: [HACKERS] Open Items (was: RE: [HACKERS] Beta going well)
Previous:From: Zeugswetter Andreas SB SDDate: 2001-11-15 08:33:10
Subject: Re: [HACKERS] Open Items (was: RE: [HACKERS] Beta going well)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group