Re: RFC: On-the-fly tainting via $^T
On Wed, Aug 02, 2000 at 11:29:40AM -0400, Dan Sugalski wrote: I was figuring the taint/notaint pragma would control taint checking, while -T would control taint setting. Probably not the best way--might be worth unconditionally setting the taint status so a use/no taint would do the right thing. Sounds reasonable. Graham.
Re: RFC: On-the-fly tainting via $^T
Ariel Scolnicov wrote:
Unfortunately, this would mean your example above doesn't quite work.
One possibility is to say that $^T controls taint *checking*, but not
tainting itself[1]!
This is actually a good distinction that's worth some more discussion.
One could set the implementation so that you still had to use -T if you
wanted tainting, but could selectively turn taint *checking* off in a
scope by setting $^T = 0 (trusting any *data* used).
So perhaps:
#! perl -T
# [ ... ]
{ local $^T = 0; $ENV{PATH} = $unsafe_data; }
# [ ... ]
system "sh -c echo 'Hello, world!'"; # ?
However, the question here is: "Would $ENV{PATH} be tainted?" If so, I
would argue you don't gain much, since the system() call would still
result in an "Insecure dependency" error.
Also, this presents a problem:
#! perl
# [ ... ]
$^T = 1;
If -T is specified, we can turn tainting on. However, if $^T is only a
toggle for taint checking, then there are three possibilities in this
example:
1. Tainting must always be on, just in case the user sets $^T
2. The above example generates an error, like "Invalid attempt
to turn tainting on with $^T (must specify -T switch)"
3. Some type of pre-parsing must occur, looking for $^T ahead
of time so that it can work like -T.
-Nate
Re: RFC: On-the-fly tainting via $^T
Another note: your examples with:
local ($^T) = 0;
$ENV{PATH} = read_config_file();
local ($^T) = 1;
is only using local() to confuse; it should be written with a block,
correctly restoring the old value of $^T.
Sorry about that - I contemplated taking it out but actually thought it
would help clarify for those familiar with the whole { local($^W) = 0;
create_a_warning() }. You're completely right.
Footnotes:
[1] For efficiency, you'd probably still want some command-line
option, perhaps -T itself, to say "this program involves taint
checking, so please keep track of tainted values". That way programs
that keep $^T == 0 (almost all of what I write) don't need to keep
track of tainting.
Definitely. I didn't want to eliminate -T at all, just give a means for
dynamically controlling it within the script as well. The idea would be
that tainting wouldn't be turned on unless -T, $^T = 1, or possibly "use
Taint" (another suggestion) was specified.
You've got some other excellent points in there regarding emphasis on
data and not variables that I'll add to further revisions.
As Tim points out, this is probably more perl6-language. I'll keep the
discussion over there on subsequent posts until something is
"finalized".
-Nate
Re: RFC: On-the-fly tainting via $^T
At 11:57 PM 7/31/00 -0700, Matthew Cline wrote:
On Mon, 31 Jul 2000, Nathan Wiger wrote:
Instead, it would be really cool if Perl6 let you do this:
#! perl -T
local($^T) = 0;
$ENV{PATH} = read_config_file();
local($^T) = 1;
I would prefer something like:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
In other words, either make the 'Taint' and 'Untaint' packages part of the
standard distribution, or put them into the core language.
While a way to taint something could reasonably be part of the main
distribution (which'd be nice), I think I'd prefer to leave untainting to
regexes.
What I was thinking of was something along the lines of a lexically scoped
pragma--"use taint"/"no taint". (We could do this by sticking in an opcode
to set/unset the tainting status, as well as the warning status, and so on)
Taint checking is disabled in a no taint block. Whether we still set the
taint status on a scalar could depend on the -T switch, so data would still
be tainted in a no taint block.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC: On-the-fly tainting via $^T
On Tue, 01 Aug 2000, Dan Sugalski wrote: At 11:57 PM 7/31/00 -0700, Matthew Cline wrote: Something else which might be useful for tainting would be something like: taint_var($foo); no_taint_var($bar); With this, any value assigned to $foo would become tainted, and any value assigned to $bar would become untainted. While this is certainly doable (heck, you can do it now with tied variables), I'm not at all comfortable with a magic untainting variables. I think it's a rather bad idea. Shrug 'Twas just an off-the-top-of-my head idea; not something I'd really fight for in the inclusion of Perl6. -- Matthew Cline| Suppose you were an idiot. And suppose that [EMAIL PROTECTED] | you were a member of Congress. But I repeat | myself. -- Mark Twain
Re: RFC: On-the-fly tainting via $^T
At 02:52 PM 8/1/00 -0400, Chaim Frenkel wrote: Please explain how having a no taint block would still keep the spirit of not making untainting easy? Hadn't thought that much about it. That is an issue which'd need to be dealt with if this proposal goes anywhere, which it very well might not. "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I think I'd prefer to leave untainting to regexes. DS What I was thinking of was something along the lines of a lexically scoped DS pragma--"use taint"/"no taint". (We could do this by sticking in an opcode DS to set/unset the tainting status, as well as the warning status, and so on) DS Taint checking is disabled in a no taint block. Whether we still set the DS taint status on a scalar could depend on the -T switch, so data would still DS be tainted in a no taint block. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC: On-the-fly tainting via $^T
Please explain how having a no taint block would still keep the spirit of not making untainting easy? Just add a no taint at the top of ones code, and the -T goes away. chaim "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I think I'd prefer to leave untainting to regexes. DS What I was thinking of was something along the lines of a lexically scoped DS pragma--"use taint"/"no taint". (We could do this by sticking in an opcode DS to set/unset the tainting status, as well as the warning status, and so on) DS Taint checking is disabled in a no taint block. Whether we still set the DS taint status on a scalar could depend on the -T switch, so data would still DS be tainted in a no taint block. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC: On-the-fly tainting via $^T
Simon Cozens [EMAIL PROTECTED] wrote: On Tue, Aug 01, 2000 at 01:43:05PM +0100, Graham Barr wrote: Let me just say that Larry has said in the past that untainting was deliberatly left difficult to do, on the basis that something which can have serious effect (ie security) should not be easy to do. But then I suppose all previous decisions are up for re-deciding Yes, they are. If we're going to make it trivially easy to untaint, should we bother having tainting at all? :( Tainting has potential uses as data-tracking mechanism aside from security. If the keyword 'untaint' had to appear, it would be easier to find security issues than when m/(.*)/ is used. Uh-oh, now we're getting back into perl6-language territory... attempting to CC. -- John Tobey, late nite hacker [EMAIL PROTECTED] \\\ /// ]]] With enough bugs, all eyes are shallow. [[[ /// \\\
Re: RFC: On-the-fly tainting via $^T
On Mon, 31 Jul 2000, Nathan Wiger wrote:
Instead, it would be really cool if Perl6 let you do this:
#! perl -T
local($^T) = 0;
$ENV{PATH} = read_config_file();
local($^T) = 1;
I would prefer something like:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
In other words, either make the 'Taint' and 'Untaint' packages part of the
standard distribution, or put them into the core language.
Something else which might be useful for tainting would be something like:
taint_var($foo);
no_taint_var($bar);
With this, any value assigned to $foo would become tainted, and any value
assigned to $bar would become untainted.
Also:
my $fh = new FileHandle("trusted_config_file");
$fh-setTrusted(1);
Then anything read from $fh wouldn't be tainted, rather than having to
untaint every single thing read from $fh.
--
Matthew Cline| Suppose you were an idiot. And suppose that
[EMAIL PROTECTED] | you were a member of Congress. But I repeat
| myself. -- Mark Twain
