Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Re: Restricted' data, a clarification

by jarich (Curate)
on Feb 12, 2004 at 05:16 UTC ( [id://328480]=note: print w/replies, xml ) Need Help??


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

So, if the goal is to keeping newbie programmers from using a variable without first running a subroutine on the variable, what is to say they can't use a weak subroutine to "clean" a variable?
filter CreditCard, sub { return $_ };

Exactly the same thing that stops a newbie programmer from using the regular expression /(.*)/ to untaint their variables. Nothing. Except if you saw that kind of untainting going on, you'd be even less willing to trust their code.

This idea isn't about protecting newbies from themselves. It's not about trusting fellow programmers or not trusting them. It's not about preventing someone from editing your code or passing around the "gateway variable" (although I don't quite understand what you meant by that). There's no point in building in "security" like this into scripts that other people can edit. Particularly since all of this could be turned off by commenting out or deleting whatever turned it on.

This idea is about assisting experienced, professional coders in their coding. It's about making sure that we don't do stupid things like print out a variable, made up of data that should be restricted, to a log file because it's 3am in the morning and the coffee's worn off.

Yes the key is under the mat. It's under the mat in taint checking too. A perfect coder shouldn't ever need to turn on taint checking because that coder would always clean variables coming in from tainted sources. However, that's no excuse for not turning on taint checking anyway. It doesn't cost a lot and is important because that perfect coder's code might be edited by me sometime in the future. I'm not perfect.

Essentially security should deal with external sources getting at data -- other users, other programs, networked or not. When you can't trust your own code, that's sandboxing, and is a different problem.

I can trust my code to have bugs in it. I can trust that some of my code will grow past 2000 lines long and that I may not be the sole maintainer of it. I can't always trust that this innocuously named variable $string hasn't collected some restricted data along the way that I shouldn't be printing out to STDERR. It would be nice to have something assist me by keeping track of that information at a lower level, and dying or filtering the string when I attempt to print it to a log file I can't easily truncate. This isn't sandboxing in the sense that I understand sandboxing.

Does this help explain my reasoning behind our suggestion?

jarich

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://328480]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-04-19 13:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found