Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: 'Restricted' data, an additional security mechanism for Perl.

by Vautrin (Hermit)
on Feb 08, 2004 at 19:23 UTC ( [id://327496]=note: print w/replies, xml ) Need Help??


in reply to 'Restricted' data, an additional security mechanism for Perl.

First off, I'd like to mention that a large part of security does not rest with the programmer; it rests with the operating system. If your operating system allows an attacker to gain access to swap space, they can scan if for senstitive information. If your operating system allows an attacker to access memory that isn't his or hers, they can (once again) scan for senstitive information. (This is, by the way, why the OpenBSD project encrypts swap space.)

Having said that, I think it would be great if some kind of Restricted Data switch was available, i.e. by calling restrict ($var); only I/O conduits marked safe for restricted data could use it. I would also love to see some kind of encryption built in, so that even on OSes that allow programs to peek at the private data of other programs, it would be impossible to understand the data -- een if it could be viewed. (Although it is important to point out that an attacker could look for encrypted data -- because they would know it was valuable, and if the encryption could be compromised this would be much more insecure then if the data wasn't encrypted)

What mechanism (if any) should be providing for 'cleaning' restricted data (eg, so only the last four digits of your credit card number can be shown)? Regular expressions are the obvious choice.

I think that people should be able to create subroutines to "unrestrict" their data, since they are the ones restricting its use in the first place. So you could create a subroutine to chop off the first 12 digits of a credit card number, to X out the numbers in a bank account, or whatever you deemed suitable.

Should there exist a hierachy of restricted information (Eg, 'Top Secret' data cannot be sent via a 'Secret' channel, but the reverse would be fine.), or should data simply be restrict/unrestricted, in the same way that data is either tainted/untainted.

I think that users should be able to create thier own hierarchy. You're going to run into a lot of situations where an arbitrary hierarchy won't quite fit. But if those conditions were met, or there was by default a "Secrect" -> "Top Secret" -> "I could tell you but I'd have to kill you" hierarchy that would be even better.

As far as computational cost of such a system, I think it would be negligible. The programmer would have to explicitely invoke it, and even then the only data that would need to be sepcially handled would be invoked as "restricted". Of course, this could be a problem if the restriction system worked something like the $`, $' variables -- i.e. use one slow your whole program down.


Want to support the EFF and FSF buy buying cool stuff? Click here.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2024-04-18 05:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found