in reply to Restricted' data, a clarification
in thread 'Restricted' data, an additional security mechanism for Perl.

Here are some potential issues:

1. In a long project, how would I figure out which data is restricted? If the data is restricted 2,000 lines above where I tried to use it, short of an egg hunt, how would I know? (Seeing if the program dies when trying to print is an unacceptable solution.)

2. If I unrestrict the data for an operation, do I need to restrict it again? What if I forget, since I might have dozens of restricted variables? One omission could be disastrous.

3. And would people become more careless, thinking they are safe with this proposed option? (Read #2)

Replies are listed 'Best First'.
Re: Re: Restricted' data, a clarification
by jarich (Curate) on Feb 13, 2004 at 01:30 UTC
    1. Finding out if data was restricted?

    How do you currently find out what data is tainted? Taintedness spreads the same way as I expect restrictedness would, that is any operation (including assignment) involving restricted data ends up with the result being restricted too. At the most simple you could do this: 

    sub is_restricted 
{
     my ($in) = @_;
     my $cmp;
     eval { $cmp = qx/echo $_[0];/ };
     if(@_ or $cmp ne $in) {
           return 1;
     }
     return 0;
}

    [download]
    just as you can write a very similar one to detect tainting. This subroutine catches the error if there isn't a filter and otherwise sees if the filter performed any changes. It doesn't catch the case where your filter is useless however. If you think that knowing if something is restricted is important we can probably write something in for checking it.

    2. Unrestricting/Re-restricting

    How would you unrestrict the data for an operation? The suggested filter idea I provided only "unrestricts" the data on its way out. Every operation using restricted data results in a restricted output, just the same as every operation (excepting capturing from a regular expression) on tainted data results in a tainted output.

    As I'm uncertain as to what motivation there would be in unrestricting data internal to the program, the issue of restricting it again doesn't come up.

    3. Encouraging carelessness

    If using taint checking encourages programmers to become more careless - because the taint checking will rescue them, or if using strict and warnings encourage carelessness then this certainly will. Even if those things don't cause carelessness in certain programmers this might.

    I'm inclined to generalise programmers who might use this feature into two groups relevant to this discussion. You have the good programmers who know that printing out passwords, private information and credit card numbers to logs is a bad idea. Hopefully they'll see this as just another tool (like strict and taint) to assist them not to make mistakes, not a magic panacea. They'll code in a clean and reasonable manner which doesn't rely on strict and taint and data restrictions but uses them just in case.

    The other group are the programmers wanting to get things done now! but have heard that using data restrictions is the thing to do. These programmers may be lead towards greater carelessness because they may choose to rely on data restrictions rather than ensuring that their code is clean and tidy regardless. Unfortunately these are the same programmers who'd probably create dud filters or be prolific in granting output permissions if their programs were being constantly tripped up by these restrictions. That is, if they didn't decide to dump the whole restricted data thing first.

    There are lots of programmers in both camps. Fortunately most CPAN modules (for example) are written by people from the first group. :) And Perlmonks does a great job of helping move up from the second group.

    I hope this answers some of your questions.

    jarich

[reply]
[d/l]

In Section Meditations