[gs-devel] -dSAFER, -dPARANOIDSAFER in gs7.20

[Raph Levien]

On Thu, Apr 11, 2002 at 07:39:32PM +0200, Stefan Ulrich wrote:
> Hi,
> 
> I'd like to bring up again the issue of -dSAFER and
> -dPARANOIDSAFER in recent gs7.20 that has come up here several
> times before (see e.g.
> http://www.ghostscript.com/pipermail/gs-devel/2002-March/001414.html
> http://www.ghostscript.com/pipermail/gs-devel/2002-March/001418.html
> ),
> but of which I'm not sure what the current status is. This issue
> has also recently come up on the tex-k mailing list (when talking
> about xdvi(k)'s rendering of PS specials), and Mike Shell has
> filed a bug report for this under
> http://sourceforge.net/tracker/index.php?func=detail&aid=541856&group_id=1897&atid=101897
> 
> The problem is that gs7.20 (as of 2002-04-02) makes -dSAFER
> equivalent to -dPARANOIDSAFER, so it forbids read and write
> access to all files apart from those given at the command
> line. This will break typical end-user applications such as gv or
> xdvi(k) that want to forbid file writing with -dSAFER, but still
> be able to send files to ghostscript at run-time e.g. via pipes.

Yes, this is true, and these applications will need to change to
be able to use newer versions of Ghostscript. It's a difficult call,
but I can't think of any better way to make sure the security fixes
get propagated.

Applications have two possible approaches. First, they can be patched
to open files in "safe" mode. I wrote a patch to gv to do this. With
this patch, gv opens the file being viewed, but doesn't let that file
open other arbitrary files.

The other approach is to leave file reading open. This is still
possible in 7.20, but we didn't go out of our way to make it convenient.
One reason is that reading of arbitrary files can lead to denial of
service attacks, for example by reading files in /dev or /proc. Ray
just committed a patch to Language.htm that explains this in more
detail. The essence is:

gs -dDELAYSAFER -c '<< /PermitFileReading [ (*) ] /PermitFileWriting
 [] /PermitFileControl [] >> setuserparams .locksafe' file.ps

> In a previous mail to the gs-code-review list
> (http://www.ghostscript.com/pipermail/gs-code-review/2001-December/001612.html)
> Ray wrote:
> 
>    In a future patch which will set .LockSafetyParams true (among other
>    things) when -dSAFER is set (which will become the default), clients
>    such as GSView will need to start Ghostscript with -dNOSAFER, then
>    establish perform a 'save' and switch to the desired device prior to
>    going into SAFER mode which will set .LockSafetyParams true. Device
>    switching can later be accomplished by restoring to that save object
>    and then switching devices, followed by going back into SAFER mode.
> 
> To me this doesn't really sound like a good solution, since it
> shifts the responsability for a safety feature from a central
> point (ghostscript) to $n$ applications that will try to
> re-invent the wheel, creating a lot of maintainance problems and
> possible sources for bugs.

Unfortunately, the responsibility for security is shared between
Ghostscript and the client applications. It's not possible to attain
security by patching one and retaining backwards compatibility wit
the other.

> I'm probably missing something in this picture, but I don't
> understand why it was neccessary to change the meaning of -dSAFER
> at all: Couldn't -dPARANOIDSAFER have been provided in addition
> for programs like daemons or suid programs that also want to
> forbid read access, and -dSAFER kept as forbidding only write
> access to files?

This is definitely a possibility, and was considered. I would really
like see the applications upgraded, which is why we are making this
change.

Thanks for your input. Having to choose between security and
convenience is a tough call. I'm trying to do the right thing, but
it's possible our plan will need revising. That's why 7.20 is out
there as a development release - if it becomes clear that the change
is unworkable, then we'll revert HEAD to the 7.0x branch behavior.

Raph