Re: 'Restricted' data, an additional security mechanism for Perl.by mr_mischief (Monsignor)
|on Feb 09, 2004 at 20:00 UTC||Need Help??|
To keep sensitive data off the screen is the easy part -- the one-argument select() can do that. So can closing STDOUT (and maybe STDERR).
The hard part is making sure things bound for output file 1 aren't going to output file 2.
A rather simplistic form of this can be accomplished in plain Perl without modules so long as you only use a special restricted print sub for output. Here's an example:
Now, that's not very useful if someone throws a print() in the program instead of using the restricted printing sub. If you could throw that functionality into a moduie and use Safe or some other way to make sure that only your restricted printing module can issue a print, printf, sprintf, write, etc. then you have a good start. If one could override the built-in output statements, that'd work, too.
Part of the problem is that you don't really want to restrict a particular variable in an application when security is of such import. You want to make sure that nothing can be output except to where explicitly allowed. If you disagree with that statement and really do want to allow by default and restrict explicitly, then the example above wouldn't be too difficult to change in that direction.
I'm not really sure how well the idea will help secure applications, as I haven't thought about it yet. It shouldn't be too difficult to implement, though, even as a hack well above the core which wouldn't slow anything down when this idea isn't in use.
I'd personally, like I did here, look at the output routines first. Wrapping it up in the filehandle somehow, whether through IO::Handle, layers, tie, or whatever could be an option, but that's back to explicit restrictions instead of explicit allow.
Christopher E. Stith