Hi there,
  for my own personal use, I've been thinking on building a web interface to
POV-Ray.  It would feature a basic Editor, basic CVS and ability to render the
povray source and keep images.  If password protected, this whole thing is
simple.

  However, I am interested in opening this thing to the world to let anyone use
it.  I remember from long ago there were a few sparks about execution of files,
and inclusion of files which led to the creation of system-wide and user
permissions for these...  but there is still the ability to write and other
like that...

  What I'm asking is:  Is it possible to disable ALL potential abuse and misuse
features in povray for a user just by compiling or configuring it specially?

  If not, then my question is a bit more general:  When parsing a user script
(after dealing with encoding tricks and encapsulation tricks and so on) what
are the things i should look for?  My policy would be to reject a file
completely the moment something unusual is found (such as different encoding
inside the text, etc) and flag this user's account (so i can monitor him more
closely and possibly use his malice to my advantage, by learning from it).

Anybody know of a simple (config? patch?) solution?  Or anybody cares to inform
me of some details concerning the difficult solution?

Thanks a lot in advance! =)
  Simon

Post a reply to this message

> Anybody know of a simple (config? patch?) solution?  Or anybody cares to inform
> me of some details concerning the difficult solution?

Forgot to mention, I'm running Gentoo Linux, but I can clearly
compile/install/maintain povray manually.  Currently running vanilla kernel
2.6.29.4 (+unionfs patch).  I have several computers at home configured like
this, all are single processors.  I also have a public host which has 4 cores
total, it will clearly be the host for this project.

Thanks!
  Simon

Post a reply to this message

There easiest way to ensure safety of POV-Ray on a Linux system, is 
probably to use the OS built-in systems:

Let POV-Ray run with its own separate user account, and allow write 
access only to one single directory: The one where rendering output is 
to be written to. That should suffice for POV-Ray to run properly, it 
doesn't need to write anywhere else.

In addition, you may want to watch out for the following POV-Ray specifics:

* INI files:

Some INI file settings allow a user to execute external commands, which 
of course is a potential security risk.

The easiest way to solve this issue is to provide no way for the user to 
submit their own INI files, and instead just provide a minimalistic 
interface with options to pick from, then build an INI file from that 
information. (Make sure that /if/ you allow some string parameters, that 
you safeguard them against "INI option injection".)

Even if you do want to allow users to submit their own INI files, you 
should use a "whitelist" approach to ensure that they're safe; anything 
POV-Ray doesn't recognize as an INI option would be interpreted as a 
file name, potentially allowing INI files or POV-Ray scenes to be 
executed that you didn't check.

* Scene files:

Make sure to check all scene files and include files. Take care of the 
following. (Note that blanks may go between hash signs and the actual 
keywords!)

- "file_exists()" might be misused to try sniff for files on your computer.

- "#fopen", "#write" and "#read" might be misused to try accessing 
virtually anything on your computer.

- Texture, height field and other input files might be misused to try 
reading other files on your computer.

- The "#include" statement might me misused to circumvent other safety 
mechanisms, or to try reading other files on your computer. (Note that 
POV-Ray does accept string variables to specify the filename.)

- Some standard include files may define macros that could be used to 
circumvent other security checks; for instance, the "strings.inc" file 
defines a macro "Parse_String" that allows to have an arbitrary string 
be interpreted as a POV-Ray SDL statement.

* Resources

Some scene files or output settings might make POV-Ray hungry for 
resources, such as main memory, disk space, or simply computing time. 
Try to get a lid on all these.


I'm quite sure I forgot some.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I'm quite sure I forgot some.

  Yes: You forgot that POV-Ray has had for a long time security features
which can be specified in the ~/.povray/3.6/povray.conf file. These security
features include things like which directories a scene file is allowed to
read and/or write. This feature was added at some point precisely for this
exact purpose.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> I'm quite sure I forgot some.
> 
>   Yes: You forgot that POV-Ray has had for a long time security features
> which can be specified in the ~/.povray/3.6/povray.conf file. These security
> features include things like which directories a scene file is allowed to
> read and/or write. This feature was added at some point precisely for this
> exact purpose.

No, I didn't forget: I just never knew. I do know that such rules exist 
for Windows, but wasn't sure about Unix. From the Windows docs, it would 
appear that they were limited to Windows to mimick file access rights 
you'd have on a Unix box.

Post a reply to this message

This sounds like a bad idea. Your system can easily run out of memory and bog
down with several people rendering, especially if they decide to render
poster-size images.

Post a reply to this message