|No such thing as a small change|
'Restricted' data, an additional security mechanism for Perl.by pjf (Curate)
|on Feb 08, 2004 at 10:30 UTC||Need Help??|
Background: I am currently in the process of writing a training course, and potentially a book as well, that deals with Perl security. The topic which follows is the result of a discussion I had with jarich on a train. The purpose of this node is to foster discussion and ideas on what may be a worthwhile addition to Perl's existing security features.
Update (12th Feb 2004): This was originally posed as an academic question, with the intention of the mechanism to act as an extra layer of protection for experienced programmers, in much the same way as strict, warnings and taint checks provide extra safety. jarich presents an excellent explanation and response on this.
My apologies to anyone who thought that this was intended instead of other security mechanisms. This was certainly not my intention. The thoughts presented here are instead intended as an additional tool for the experienced programmer who wants additional safety layers to protect against programmer error.
Perl has a concept of 'tainted' data. Data that is considered tainted cannot be used to open files or used with anything involving the shell. It's a great way of stopping uncleaned data from being used where it should not.
However, to my knowledge there is no mechanism in Perl to prevent private data from being used where it should not. 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.
There are programming practices that can help prevent this (eg, undefining the variable as soon as you're finished with the sensitive information), but no inbuilt mechanism to prevent accidental disclosure. As such, I'd like to float the idea of 'restricted' data.
'Restricted' information cannot be sent to an I/O boundry which is not specifically marked as being able to accept restricted data. In our credit card example above, the connection to the credit-card processing facility would be marked as being able to accept restricted data, but everything else would not.
In the same way that the result of any expression involving tainted data is tainted, the result of any expression using restricted data would also be considered restricted.
There are many applications for such a framework. Passwords, encryption keys, and other sensitive data in many systems can be marked as restricted, providing an extra safeguard against them inadventantly being revealed. In government or military systems, classified information could also be marked as restricted.
I'm hoping to gauge the community's feel for both the need for restricted data, and also any input on what may be felt as the best way to implement these features. As such, I have a few questions I would like to pose:
As stated in the introduction, the purpose of this node is determine if the idea has merit, and to discuss the best way to progress forward if it does.
All the very best,
Perl Training Australia