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
in thread 'Restricted' data, an additional security mechanism for Perl. by pjf

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.