in reply to A Quest for Taint

Unfortunately, the Perl executable must be started with taint mode enabled. That means you're going to have to be ultra careful. Taint will not be terribly useful here as you can't use it to taint data unless taint checking is already enabled.

If you can pass control to the other script which is in taint mode, that might be an idea, but it's going to be very slow.

What I try to do in a situation like this is I group all of the scalars that should normally be tainted close to the top of the program and I attempt (if possible), to "untaint" them there. Often, if taint checks are enabled, untainting is scattered throughout the program. If taint checks are not enabled, it's much tougher to easily determine where you want to untaint data. By grouping this data -- and liberally commenting so others understand why it's being done -- you can create a "red flag" for programmers that follow.

I, for one, would KILL to be able to enable taint checking "on the fly," but I suspect that it would not be a trivial task to accomplish.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: (Ovid) Re: A Quest for Taint
by mirod (Canon) on Dec 12, 2000 at 23:55 UTC

    I would think undef-ing all remaining tainted variables once you're done untainting would add a little more security, as it would prevent re-using them by mistake.

[reply]
Re: (Ovid) Re: A Quest for Taint
by Blue (Hermit) on Dec 13, 2000 at 18:41 UTC
    I, for one, would KILL to be able to enable taint checking "on the fly," but I suspect that it would not be a trivial task to accomplish.

    Does anyone know if there was an RFC for this for Perl 6? I've seen it come up a few times here, which means need for it is not just an isolated incident.

    =Blue
    ...you might be eaten by a grue...

[reply]

      This is more than just something that would be 'nice' to have. I'm working hard to get perl accepted as a approved development language where I work, and insisting on taint mode is a big key on selling perl security.

      We are a large corporation with tons of beaurocratic steps at every phase of development, staging, and production. We have one brave development group that's pushing forward with a huge perl dependant application that's just hit a huge problem with taint mode.

      The application is actually part of numerous enviornments so the paths to the libraries change with each execution depending upon $ENV{USR_LOCAL_LIB_PATH}. With no way to untaint the $ENV{USR_LOCAL_LIB_PATH} prior to execution time there is no way to update the @INC at compile time.

      The only way I can see around this is to establish separate perl binaries/libraries for each enviornment... not an easy thing to do with separate sysadmin, security, and development beaurocracies all with hands mucking up the machinery of progress.

      I don't suppose anyone see's another way around this? (Hardcoding the lib paths is NOT an option.)

      coreolyn Duct tape devotee.
      -- That's OO perl, NOT uh-oh perl !-)

[reply]
        I'm having trouble understanding the issue here... $ENV{USR_LOCAL_LIB_PATH} has to be set at compile time, or you wouldn't be able to update @INC at compile time anyway. So, if $ENV{USR_LOCAL_LIB_PATH} is set at compile time, why can't you untaint it at compile time?
[reply]

In Section Seekers of Perl Wisdom