Pathologically Eclectic Rubbish Lister | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If I have a credit-card number that I wish to process, then I don't want that being printed to the screen, to a log-file, saved to disk, and definitely not sent out in an e-mail. Then don't do any of those things. There isn't any safeguard for programmer error. It happens all the time. You're correct, there is no safeguard for programmer error, but it is possible to add mechanisms to make it more difficult for the programmer to make mistakes without taking steps to get around those mechanisms. Taint checks are a close anaology to the idea of restricted data. By requiring that you clean your data before using it, the programmer is required to give thought to that process. Even a good programmer will make mistakes at times, and taint checking helps avoid these. Even the use of strict and warnings won't stop programmer mistakes, but they go a long way to catch many of the common ones. The idea of restricted data is the same -- to provide a mechanism whereby programmers need to go to more effort in order to make a mistake. A very good real-world example of this is when something goes wrong and the program generates an error message. We don't want sensitive data in that message, even if the subroutine which generated the error was dealing with sensitive data at the time. It's not a trivial task for your (potentially third-party) subroutine to tell whether or not its arguments are sensitive. As for a lot of security being provided by the operating system (mentioned in other responses), I quite agree, but the operating system is only part of a complete security solution. There's a long history of very secure machines running very insecure programs, and vice-versa. In the case of the proposed restricted data mechanism in Perl, we may be able to signal to the operating system that such data should be treated in a special way -- eg, by using secure (non-swappable) memory to avoid sensitive information being written to a swap file. The comments that such a mechanism would incur a higher overhead are well founded, and not something I had previously given much thought. I imagine that the overhead would be similar to that incurred by turning on taint checks. One would hope that any implementation would give developers a choice as to the use of restricted data, in the same way that one has a choice as to whether or not taint checks should be used. Many thanks to everyone for the feedback, it is very much appreciated.
Paul Fenwick Perl Training Australia In reply to Re: 'Restricted' data, an additional security mechanism for Perl.
by pjf
|
|