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

[pjf]

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.

[flyingmoose]

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.

This statement scares me. If this were true, and there were no programmers of any worth in the world, we'd need to throw away all of our C and assembler code right now. It's too easy to make mistakes. Nope, a good programmer tests his code, and better yet, has folks test his code for him. Shepherding is all well and good, but it is no substitute for education, analysis, and foresight.

If you can't trust the software you are running, then it's really a lost cause in all languages. A programmer who needs to write "use restricted variable yes I really mean it", can abuse this just as well as any other variable. In the real world, private access isn't there for security reasons, it's there for a much better reason -- locking an API down to enforce an interface.

Other languages that have private access can usually access private variables through either reflection/symbol-tables or native bindings (example: I can read & write private variables in Java using both reflection and JNI).

So, adding additional security 'features' into a language may only give a false sense of security, odds are that injection attack or cross-site-scripting bug is still there, as it's an algorithmic/implementation bug rather than a language issue.

Having security features can often be misleading. For instance, I know of a certain application that saves passwords BASE64 with world-readable permissions. I know of another that saves passwords plaintext. Local-socket exploits too. The language can't shield you from any of these, and often these sort of problems are the worst kind.

Security, essentially, is needing to know all of these things. They can't all be fixed in terms of language usage. It takes a very strong programmer to know what code is insecure and what isn't.