homepage

This might just add unnecessary bloat, but since Python is being 
used in CGI scripts, it can be used to narrow a security hole. One way 
of breaking security is for a naiive programmer (don't try to deny 
their existance) to run an arbitrary command from the page 
viewer.
Perl has developed an interesting mechanism for 
helping with this: taint. The way it works is, when something comes 
directly from the user, like a key in a form, it is considered to have 
taint unless specifically untainted. Things like os.exec() would 
create a warning message if you passed tainted strings to 
them.
As I said, this might just add unnecessary bloat, but for 
an option that can be left out for most builds of Python I think it 
would be pretty nice.

Logged In: YES 
user_id=105956
I really like taint mode.
I think this would make Python a better choice for CGI scripts.
See http://www.perldoc.com/perl5.8.0/pod/perlsec.html
and http://gunther.web66.com/FAQS/taintmode.html
for more background.

Logged In: YES 
user_id=44345
Took awhile for a response to this feature request. ;-)
Perl's heavy integration of regular expressions with its
taint facility probably wouldn't work all that well in
Python. For one, Python has more ways of searching
strings than with regular expressions. Second, regular
expressions are not nearly as tightly wound into Python
as they are in Perl. I think you'd have to add a taint
attribute to strings and just rely on the programmer to
properly clear that attribute.
I think a first cut at an implementation would go much
further toward getting the concept seriously considered
for addition to Python.

Logged In: YES 
user_id=72053
With new-style classes, maybe this can be done by
subclassing string somehow. There would be a subclass for
tainted strings and trying to do most things with them would
raise an exception. With taint checking enabled, functions
like os.getenv and cgi.FieldStorage would make objects
containing tainted strings. You'd untaint them by passing
them to re.search or re.match and pulling out the match
variables, like in Per.

Logged In: YES 
user_id=252564
Thanks for the idea, phr. I wrote a small class called 
TaintString, derived from string, that has a taint attribute. This 
is probably the least difficult part. The difficult part will be in 
modifying functions like os.system() to raise warnings or 
exceptions when tainted strings are passed to them. I'm 
currently thinking of making wrapper modules with names like 
taint.os, or taint.cgi, but the problem with this is that you 
have to manually use taint.* for certain functions. If anybody 
can think of something that can simplify this, please post it.

I have come up with a class called SafeString which is the opposite of a tainted string. In my model, all strings are tainted by default, and you have to call untaint() to create a SafeString. Then I replace all functions in the os module with wrapper functions that check all parameters first and raise TaintError if any string is not safe. If I can figure out how to attach a file here, I will post it. Otherwise you may find it on comp.lang.python by the name of taint.py.

http://svn.rocholl.net/taint/trunk/taint.py 

On http://mail.python.org/pipermail/python-dev/2008-November/083732.html
Nicole King wrote:
"""
I found I needed support for taint mode in python and have done some
work to realise this. It's by no means complete at this time, but I'm
floating this idea on this group to see how much interest there is.
The implementation is pretty simple:
- an extra field in PyObject to maintain the taint status
- a couple of extra functions __gettaint__() that returns the taint
status and __settaint__(value) that sets the taint value, returning the
previous status
- an additional command-line flag -a and environment variable
PYTHONIGNORETAINT that suppress taint checking
- a few macros defined in Objects/object.h to support taint management
- a new built-in exception, PyExc_TaintError, for reporting operations
on tainted objects
"""
More information and download: http://www.cats-muvva.net/software/ 

This is too vague and too large an issue to be tracked by an RFE issue.
 Concrete proposals and implementations must go through the PEP process.