Abigail's comment sounds right on the mark, a magic security attribute might be useful. I also wonder if -T could be pressed into service without stir-frying XS, though that might not be so useful.

To add something of my own, I once mentioned on PM when I was writing a shopping cart app that did realtime credit card billing, that I was disconcerted at being able to find the credit card numbers by grepping the linux swap file after perl had quit. People said, well yeah. I was able to solve this I think by overwriting strings with garbage of the same length and then undefing them.

Also I wrote an easy to use wrapper I call QuickCrypt.pm which I sometimes use to quickly encrypt and websafepack form data with different algorithms.

I am reminded of lazy loading in Class::DBI which, if it new which fields were sensitive, might be induced to keep them unread normally. Perhaps just adding some patches to common modules to let them know some data is sensitive might be useful.

Anyway while developing channels to intentionally restrict your own actions is one thing, I wouldn't mind the converse as well, that is to restrict outsiders (say on a shared server) as much as possible from potentially viewing your data.

There is a danger of being seduced by obfuscation and not getting real security, but some things that pop into mind are:
- overwriting used data
- providing an encrypted ipc cache in ram
- transparently encrypting/decrypting sensitive scalars and lists so they are seldom visible (interpreter could generates a key when launched but that key will be in memory..)
- maintaining an ongoing encrypted io stream which data could be injected into without being obvious
- generating a noisy stream that is hard for traffic analyzers to pull apart.

These things all have in common the idea of keeping an admin of a shared server (or a malicious piece of spyware) in the dark as much as possible, and to remove clues about running processes. I don't know if any of these really would work against anything but the simplest thieves though. Anyway it seems that as long as you keep both eyes open, everything is relative. So if you can get perl modules, the interpreter, the os or the underlying hardware/network to cooperate with you I'd say you have a fair chance of relative success. Probably I'd guess ease of use would be the second most important thing after adding some magic like Abigail suggests.

In reply to Re: 'Restricted' data, an additional security mechanism for Perl. by mattr
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.