untaintby property

[mosul...@crtinc.com]

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/ .

[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

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

[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

[mosul...@crtinc.com]

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.

[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 (ad...@cec.wustl.edu)
http://cec.wustl.edu/~adam/

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

[Michael G Schwern]

On Mon, Oct 14, 2002 at 10:09:41AM -0400, mosul...@crtinc.com 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 <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Do you have a map? Because I keep getting lost in your armpits.