Perl has a really neat feature called taint mode ( T ). With that mode enabled, any variable that comes from the outside world (env vars, GET/POST data, etc. ) is tainted, and any variable that touches a tainted variable is also tainted. Tainted variables can't be used in methods that touch the outside world (SQL, exec/system, etc).
The only way to untaint a variable is to do a regex on it; any matched groups are untainted. Of course, you can get around taint mode by doing a regex for (.*) but the idea is that you have to actively write bad code like that -- rather than just carelessly forgetting to sanitize your inputs -- if you're going to do something dumb like concatting user input straight into MySQL.
Perl has a really neat feature called taint mode (-T). With that mode enabled, any variable that comes from the outside world (env vars, GET/POST data, etc. ) is tainted, and any variable that touches a tainted variable is also tainted. Tainted variables can't be used in methods that touch the outside world (SQL, exec/system, etc).
The only way to untaint a variable is to do a regex on it; any matched groups are untainted. Of course, you can get around taint mode by doing a regex for /(.*)/, but the idea is that you have to actively write bad code like that -- rather than just carelessly forgetting to sanitize your inputs -- if you're going to do something dumb like concatting user input straight into MySQL.
1 Wow, that's really interesting – Gravity 3 hours ago.
The E programming language is based on capability security model in which access to objects, possibly distributed on different systems, is only available via explicit "capabilities" that a program must manage. The only privileges a piece of code has is the rights passed in via capabilities by its "maker" when it is instantiated. The idea is for a powerbox shell to grant privileges to pieces of code as they execute.
What's a little surprising is that this is similar to the Erlang concurrency primitives -- the ability to contact an Erlang process requires knowing the pid of the process -- which means another process granting the privilege by communicating the pid. (Of course, Erlang also has registered processes, which can be referred to by name. And, Erlang also uses a simple cookie scheme for remote system access, and access to executing underlying file IO commands on remote nodes aren't locked down.
Erlang minus a few features could easily be an incredible sandboxed-execution environment, but I have no idea how much work it would take to remove those features. ) Ruby also has a Taint environment, similar to Perl's Taint environment as described by yshavit. Would I trust any of these systems exclusively to execute potentially malicious code?
Probably not. There are environments such as constructed by codepad. Org to confine execution of untrusted code using active debugging facilities.
Those are useful too, but I'm not sure how far I would trust them, either. I'd trust something more like QEMU+KVM / VMWare / Xen more, or OpenVZ/vServers, or a mandatory access control tool such as AppArmor, SELinux, TOMOYO, or SMACK. (I've worked on AppArmor for over a decade, so I'm a bit biased towards it as a solution for many people.
The others are fine tools which make more sense for different deployments. ).
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.