Re: untaintby property

[Austin Hastings]

I think that if a package deliberately tries to untaint data, and then
the data isn't untainted, there will be an error shortly.

Perhaps you could be more specific about what you mean by untainting
things which shouldn't be untainted? Did you mean globals?

Otherwise, I'd think that if a package author untainted data, you
should let him have it untainted. If the data wasn't untainted
CORRECTLY, that's a bug. But otherwise?

=Austin

--- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 SUMMARY
 
 The 'untaintby' property restricts which modules may untaint the data
 or
 data derived from that data.
 
 DETAILS
 
 I was recently using a module I downloaded from CPAN and looking
 through
 the code I discovered that it untainted certain data that it had no
 business untainting (IMHO).  The untainting was an unintended
 byproduct of
 some otherwise useful work. (See my earlier concern about untainting
 at
 http://makeashorterlink.com/?Y28261A12)
 
 Now, tainting is a funny thing: it's an admission that maybe your
 program
 doesn't work quite the way you want it to. I submit that if it's
 healthy to
 doubt the perfection of your own code (even though you run it), it's
 also
 healthy to doubt other people's code (even though you use it). I
 would feel
 a little more comfortable if I could say I'll hold back the
 untainting to
 just my own code.
 
 Here's my little brainstorm.  Objects can be marked with a property
 called
 'untaintby'.  The value of the property is a list of modules that are
 allowed to untaint the data.  Example:
 
   my $command is untaintby('MyApp::Commands', 'Util::IdCheck')
 = CGI.param('command');
 
 Any module that isn't authorized by that list cannot untaint the
 data, and
 cannot derive untainted data from it.  No error results from a class
 trying
 to do an unauthorized untaint: the data just isn't untainted.
 
 So, for example, if the data were copied into $privatecmd in
 Foo::Bar, that
 copied value would inherit the untaintby property.  If a regex were
 run
 against $privatecmd...
 
   # bad untainting, bad!
   $mycmd =~ m|([^!-`])+|; 
   $newcmd = $1;
 
 ... $newcmd would also inherit the untaintby property, and would
 still be
 tainted. Modules may further restrict the untaintby property (i.e,
 shorten
 the list) but they may not add to it.
 
 The module that initially sets the untaintby property is by default
 included in the list, so to restrict to just the current class you
 could
 say 
 
   my $command is untaintby() = CGI.param('command');
 
 (Hmm, I'm not sure about that, though.  It isn't clear just reading
 it that
 the current module can untaint. What do you think?)
 
 -Miko
 
 
 
 
 mail2web - Check your email from the web at
 http://mail2web.com/ .
 
 


__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos  More
http://faith.yahoo.com

Re: untaintby property

[Larry Wall]

If properties aren't entirely passive, then it may be possible to
register a callback on the tainted property itself that defeats any
misguided attempt to untaint it.  It's unlikely to protect against
malicious attempts, however.

Larry

Re: untaintby property

[[EMAIL PROTECTED]]

Larry said:
 If properties aren't entirely passive, then it may be
 possible to register a callback on the tainted property
 itself that defeats any misguided attempt to untaint it.

Callbacks on properties? That's too cool.  By doing callbacks on tainted
and on taintby, a module could be written to implement my ideas without
having to fiddle with the language itself.  Too groovy.

-Miko



mail2web - Check your email from the web at
http://mail2web.com/ .

Re: untaintby property

[Adam D. Lopresto]

I'd say the correct solution isn't to control which modules can accidentally
untaint data (it seems pretty likely that no matter what we do, maliciously
coded modules will be able to screw you over if they try to do so
intentionally) but rather fix those aspects of tainting that allow any module
to accidentally untaint data.  Personally, I think untainting data should
only be the result of an explicit untaint function, but maybe that's going
too far.
-- 
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/

Her hair glistened in the rain like nose hair after a sneeze.
(Chuck Smith, Woodbridge)

Re: untaintby property

[Michael G Schwern]

On Mon, Oct 14, 2002 at 10:09:41AM -0400, [EMAIL PROTECTED] wrote:
 SUMMARY
 
 The 'untaintby' property restricts which modules may untaint the data or
 data derived from that data.

 DETAILS
 
 I was recently using a module I downloaded from CPAN and looking through
 the code I discovered that it untainted certain data that it had no
 business untainting (IMHO).  The untainting was an unintended byproduct of
 some otherwise useful work. (See my earlier concern about untainting at
 http://makeashorterlink.com/?Y28261A12)

The concern here seems to be more about unintentional untainting rather than
deliberate untainting by unauthorized parties.  Rather than add an
additional, explicit security system on top of an implicit security system,
the causes of unintentional untainting in the language should be reduced.

Something in the family of your original /T regex proposal would make more
sense.  Attack the problem at its source.


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance  [EMAIL PROTECTED] Kwalitee Is Job One
Do you have a map? Because I keep getting lost in your armpits.