This is a cut/paste of a comment I posted to /.
The root cause of all of these security problems has been in plain sight since 1970 or so, yet only a few people are even aware of it. It's obvious once you get it, and the scope of fixing things comes clearly into place. So, do you really want to take on forking every program to build a new version of it? If so, you can fix it, if not... this will continue to happen, and government will try to fix it by fiat, badly.
The root cause of all of these security problems has been in plain sight since 1970 or so, yet only a few people are even aware of it. It's obvious once you get it, and the scope of fixing things comes clearly into place. So, do you really want to take on forking every program to build a new version of it? If so, you can fix it, if not... this will continue to happen, and government will try to fix it by fiat, badly.
The cause is that our operating systems operate on the assumption that programs can be trusted. This makes it almost impossible to launch an executable safely, because there is no OS enforced way to limit the side effects of execution.
Only an operating system that requires specifying the resources to feed to a given instance of execution can limit the side effects by design, instead of luck.
It doesn't have to be user-unfriendly, because the OS can always handle prompting for file names, etc... in fact if done properly, the user might not even need re-training to use the new fork of their favorite program, because for their intents and purposes, it acts the same, with the same dialog boxes, etc.
The principle of least privilege is the solution to this whole mess, but it has to be applied from the kernel all the way up the stack. This is a lot of forking work to do.
Do you dare to take up the challenge, or will you let someone else try the latest band-aid instead?
No comments:
Post a Comment