[mod_python] security issues

Also:

10. Especially if using mod_python.publisher, don't use the same name 
for Python code files (module names) in multiple places. This is 
because there are bugs in its implementation which can cause cross 
contamination of modules, the loading of the wrong module and other 
issues. See:

   http://issues.apache.org/jira/browse/MODPYTHON-9
   http://issues.apache.org/jira/browse/MODPYTHON-10
   http://issues.apache.org/jira/browse/MODPYTHON-11

11. If multiple people share the same web server, use PythonInterpreter 
to assign your area of the web site its own instance of the Python 
interpreter. This isn't fool proof as another user could do the same 
thing and use the same name. When working though, it will keep your 
stuff separate from others and avoid them being able to more easily see 
and fiddle with the internals of your running application.


Graham

On 02/02/2005, at 2:44 AM, Jorey Bump wrote:

> Lula Dog wrote:
>
>> I cannot find anything related to the python security 
>> configuration/installation...Any hints?
>> I just want to know if there are some security guidelines during the 
>> installation/configuration of Python on Unix systems...
>> Any help would be very much appreciate....
>
> Many of the same security issues that apply to other embedded 
> interpreters apply to mod_python. Here are some brief descriptions. 
> Rather than list the solutions in detail, use them as a basis to 
> search the mailing list or web:
>
> 1. Store sensitive data in modules outside of the DocumentRoot of your 
> site. This prevents modules from being exposed if mod_python isn't 
> running.
>
> 2. Don't store backup files where they can be accessed via HTTP. 
> Honestly, I'm sure I could gather about a thousand db passwords in a 
> day if I simply created a bot that crawled dynamically driven sites 
> and appended ~ to every file name it finds.
>
> 3. Use the FilesMatch directive to disallow access to important types 
> of files, such as *.pyc, *.pyo, *~, etc.
>
> 4. Understand the quirks of mod_python.publisher if you use it as a 
> handler. For example, add a leading underscore to objects if you do 
> not want them to be directly accessible via HTTP (_foo = "secret 
> word").
>
> 5. Because the embedded interpreter runs applications as the apache 
> user, all other applications may have access to the same files. This 
> can have serious implications in a multiuser environment, and applies 
> to PHP, SSI, CGI, etc., as well.
>
> 6. Avoid any kind of dependency on the PATH environment variable. It 
> can easily be changed by other applications, causing your own to fail. 
> If you must call system programs, declare the full path explicitly, 
> *always*.
>
> 7. Debugging information can be essential when developing an 
> application. Take pains to ensure that error messages don't reveal 
> sensitive data if they are returned to the browser. Review your code, 
> and use try/except statements to catch errors when appropriate.
>
> 8. Learn about Python's mechanisms to restrict what gets exported by a 
> module.
>
> 9. If your database and application are on the same machine, don't let 
> the database listen on a port exposed to the Internet.
>
> That's all I can think right now, hope it helps.
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python