Florian Gross
3/4/2005 8:20:00 PM
Daniel Berger wrote:
>>>rb_secure() and rb_tainted_string_new().
>>>
>>>When should I call these? When interfacing with underlying OS
>>>functions (as etc.c does) should it be standard practice to call
>>>rb_secure(4)?
>>>
>>>Why are so many C extensions returning strings as tainted? I mean, you
>>>don't see folks doing this in their pure Ruby code very often. Why so
>>>much on the C side of things?
>>
>>Because the tainted state spreads. E.g.:
>>
>>str1 = "foo"; str1.taint
>>str2 = str1 + "bar"
>>str2.tainted? # => true
>
> I don't understand what your point is here. So? Why aren't folks
> tainting strings more often in pure Ruby then?
Why would you taint Strings if any String that is derived from external,
insecure data is already tainted anyway?
>>However, if the String is initially created in the C extension and
>>coming from an external (untrusted) source it needs to be tainted
>>manually, of course.
>
> I'm afraid I don't follow here. Is a function call from one of the
> standard OS header files which returns a char* "untrusted"?
It depends on where the data comes from. I'd consider things like
process names, login names, environment variables and so on insecure as
they can contain data of pretty much arbitrary format.
The whole tainting feature is about protecting yourself from using
unfiltered user input where you shouldn't after all.