The deepest bug of all is the idea that you can write trustworthy code. Look at how long the integer overflow lurked in the merge sort.
Until we get rid of the need to trust code with everything, and build systems that only supply the minimum capabilities required to do a job to a given program, we're not going to have secure computing.
Here it is... the reminder that Capability Based Security can fix this, if we raise awareness of its existence, and push to get it implemented. The idea is older than Unix, for chrissakes.
The responsibility for security should be at the ends, not the middle. The middle is where you insert censorship and the canonical "Eve" who taps everyone's email and other communications.
Blaming the victim (user) isn't any smarter. They just want to use a tool. If it requires perfect knowledge of the state of the entire universe to know if it's safe to open a given file, then you can't blame them for failing to be G-d.
Capability Based Security can give a system to an end user which eliminates the need for perfect guessing and/or luck. The system only gives the rights to a program that you specify, no more, ever. It's the model which is seeing service in smartphones, etc... in which every app runs in a sandbox. The difference is that it's tighter than that even, the granularity goes to the point where you can specify access to a file, and there is absolutely NO way to see anything else. You don't ever have to trust code outside of the OS kernel.
This can be done, for less than $30,000,000. Now, can someone help me write the grant application? Does anyone want to do it?
The reason the internet is so successful is that it has a core that doesn't try to think too much. Get packet, forward packet, etc..
If load balancing is a concern, the client node should determine where the best place to get content from is at, NOT some hack which makes DNS less reliable, and noisier.
Use digital fountains and give out multiple sources to get streams from, and let the end user's computer figure it out. They are the ones in the best place to determine which is a more reliable stream of packets, not some aggregated delayed measure post facto.
I don't like this idea. Round robin should be good enough.
Instead of spending yet another astronomical amount of resources to try to patch up our "defenses", why not fund a few open source projects to get a some implementations of the Capability Security Model out into circulation?
A few well placed millions (or heck, even thousands) could fix the internet for good, and then we could all get on with general purpose computing, without the need for virus scanners, etc.
Actually, it's not the whole system that has to be inviolate, just the kernel. There are projects to produce a provable L4 microkernel, for example. This would allow the user to have a machine that they could then trust to only give away resources they chose.
Don't confuse a locked down kernel with a locked down computer. With the current OS selections you have, it's not possible to make a distiction, but it doesn't have to be this way. The problem boils down to the default permissive environment that we're all used to thinking and modeling our systems on top of. Capability based systems are a default deny environment, but you are free to give away as much as you want to a program of your choice.
It's not the Internet switching fabric that is the problem, it's the end nodes. None of our PCs is provably secure. It's highly likely it won't be by 2020 either, as it appears the money is going into the wrong places in research. Capability Based Security has been around since the 1980s, and yet it's not even being funded to try to get it ready for widespread use by 2020.
Until the ends of the internet are secure, it's not going to be secure. It almost seems the money is always being spent in places where it won't really help the end user, but will allow more control by the authorities. (Or maybe I'm just a bit paranoid?)
Y2K was mostly a result of the radical shift in the nature of software development brought about by the IBM 360 and other computers which included a new feature of backward compatibility. Prior to that time it was safe to assume that programs would only live until they needed to be re-written to run on the next generation of computer. So as a result, we had many programs living well past retirement age. This then lead to a sane design decision from the 1950's getting us into trouble 40 years later.
Now we have a similar situation with Nukes. The Test Ban Treaty radically changed the nuclear weapons development environment, and as a result our nukes are now well past their retirement age. They were meant to be replaced, but haven't been.
It is important to note that in both cases, the eventual cost are still WELL below the development and other costs which were avoided.
I learned a lot from this video Sugar: The Bitter Truth wherein Robert H. Lustig, MD, UCSF Professor of Pediatrics in the Division of Endocrinology, explores the damage caused by sugary foods. He argues that fructose (too much) and fiber (not enough) appear to be cornerstones of the obesity epidemic through their effects on insulin.
One of the things I learned is that exercise can't possibly burn off the calories you need it to for most people. The real reason exercise works is that it decreases appetite, which then reduces calorie consumption, while increasing metabolism, and is a health negative feedback loop to help stabilize weight.
If you start exercising and keep your caloric intake equal, you're negating the feedback look, and you'll have to do a LOT of exercise to do.
I think that if you learn more about the whole system, you'll approach things from a different perspective, and you can reach reasonable goals instead of constant frustration.
Since we've been going at the Personal Computer for at least 30 years, and nobody has yet caught on to the power and potential of capability based security... there is at least one quantum leap of development left to make a small fortune off of... get busy folks!
None of the widely used operating systems out there is secure. Until we embrace microkernels which have been proven to be secure, along with default usage of the object capability model, we'll never be safe.
It's possible to secure a computer to withstand the full force of the internet, even with normal users... but not with the code we have now.
Tannenbaum is right about microkernels... and Linus has reached the wrong conclusion.
I like SVN... but it's primary objects are specific versions of files, it does not deal with the changes between them as a primary object, but a means to get the primary object. When you have multiple authors, it's important to know who made what changes, and exactly what the changes were... the "Google Wave" approach is different in that each and every change is tracked, and those changes can be merged into bigger change sets if required... but the granularity is much finer and the authorship is always known.
This allows you to share a document and make multiple simultaneous changes, providing a structure to do so all the way up and down... this framework gives you a standard way to do things, that can then be expanded upon in a whole new set of ways.
Yes... this stuff could be done in a web forum... just like you could program everything in assembler... but it's more efficient in many ways to spend a little CPU time to make up for hours of developer time.
This framework will allow others to reach much, much farther and do things you can't even imagine doing via php/javascript.
Really? Wave allows multiple people to edit the same document at the same time, across company lines... AFIK, this is not anywhere on the radar at Microsoft.
The basic problem these days is that you have many people who want to have access to a shared document. The solution that Microsoft was pursuing was good, and attempted to fit the RSS model blogs use to push content. But in the end you still have many copies of documents, and you're always trying to keep changes synced across them. This approach breaks down when you have multiple sources of change... conflict resolution will always jump up to bite you.
Google Wave is a brilliant leapfrog over this problem, at the cost of some complexity. They made engineering choices that so far seem to be very pragmatic and practical... and if you don't like them you could always build your own. They actually distribute the changes to all observers, using OT (Operational Transforms) to keep everything synchronized. As a benefit, you can work on only the changes to a document, instead of having to re-scan the whole thing every time something changes, to attempt to work backwards to figure out the changes.
The ambition of Google's approach is backed up with a brilliant exploration of the solution space, and a very good choice of models, both in terms of the open source approach, in their openness with documentation, etc... and their choice of federation as a first class part of the model.
The latest analogy that I came up with is one of a Jet Engine.... instead of working on one charge of fuel/air at a time (one document)... it operates on a stream of fuel and air.... which allows for higher performance (at the cost of some fuel efficiency).
We don't care as much about the computational cycles as we do all the human time this saves by tracking all the changes, and who made them.
Slashdot sucks when it's time to try to actually learn something instead of flaming and ranting and trying to one-up each other.
The principle of least privilege is the only known approach that might possibly lead to a secure operating system... what do we do in the US? Let the only project we have fall off into obscurity.
We then deride the EU when they actually decided it would be a good idea to try to fund a project with the possibility of success.
We need secure endpoints before we can ever hope to have a secure infrastructure. We're not smart enough to even try to pursue the only known approach that might work. We're doomed. Hopefully someone will understand this, not see it as a pure rant, and learn something.
Yes, covert channels will always be an issue, as with physical security... but I think we can agree that specifying the capabilities to be given to a piece of code is a much saner way to do things than to be forced to trust your code.
Of course, the question you're probably trying to raise is why save at all? Why do modern systems still rely on a paradigm that's over a 100 years old? Maybe someday we'll come up with something that's more efficient and better organized, but right now I don't have that answer.
The problem is that we've optimized on the wrong thing, programming convenience, instead of user productivity. Computers are supposed to be a tool for humans to better manipulate symbols and information. There's no reason not to keep all of the input received via the keyboard or mouse from the user along with the context... it's tiny... a few bytes per hit, without compression. Saving the internal deltas of almost anything a typical user does with a PC are not unreasonable.
Slashdot Mirror
This problem was SOLVED by Dennis and Van Horn back in the 1960s, it's called capability based security. You can read more here: http://old.nabble.com/On-the-Spread-of-the-Capability-Approach-to5608409.html
The concept is simple, every process has a list of capabilities handed to it. It doesn't get to do anything not on the list.
It would be fairly easy to make sane default lists and still have a very usable computer.
The deepest bug of all is the idea that you can write trustworthy code. Look at how long the integer overflow lurked in the merge sort. Until we get rid of the need to trust code with everything, and build systems that only supply the minimum capabilities required to do a job to a given program, we're not going to have secure computing.
Here it is... the reminder that Capability Based Security can fix this, if we raise awareness of its existence, and push to get it implemented. The idea is older than Unix, for chrissakes.
The responsibility for security should be at the ends, not the middle. The middle is where you insert censorship and the canonical "Eve" who taps everyone's email and other communications.
Blaming the victim (user) isn't any smarter. They just want to use a tool. If it requires perfect knowledge of the state of the entire universe to know if it's safe to open a given file, then you can't blame them for failing to be G-d.
Capability Based Security can give a system to an end user which eliminates the need for perfect guessing and/or luck. The system only gives the rights to a program that you specify, no more, ever. It's the model which is seeing service in smartphones, etc... in which every app runs in a sandbox. The difference is that it's tighter than that even, the granularity goes to the point where you can specify access to a file, and there is absolutely NO way to see anything else. You don't ever have to trust code outside of the OS kernel.
This can be done, for less than $30,000,000. Now, can someone help me write the grant application? Does anyone want to do it?
The reason the internet is so successful is that it has a core that doesn't try to think too much. Get packet, forward packet, etc..
If load balancing is a concern, the client node should determine where the best place to get content from is at, NOT some hack which makes DNS less reliable, and noisier.
Use digital fountains and give out multiple sources to get streams from, and let the end user's computer figure it out. They are the ones in the best place to determine which is a more reliable stream of packets, not some aggregated delayed measure post facto.
I don't like this idea. Round robin should be good enough.
Instead of spending yet another astronomical amount of resources to try to patch up our "defenses", why not fund a few open source projects to get a some implementations of the Capability Security Model out into circulation?
A few well placed millions (or heck, even thousands) could fix the internet for good, and then we could all get on with general purpose computing, without the need for virus scanners, etc.
Actually, it's not the whole system that has to be inviolate, just the kernel. There are projects to produce a provable L4 microkernel, for example. This would allow the user to have a machine that they could then trust to only give away resources they chose.
Don't confuse a locked down kernel with a locked down computer. With the current OS selections you have, it's not possible to make a distiction, but it doesn't have to be this way. The problem boils down to the default permissive environment that we're all used to thinking and modeling our systems on top of. Capability based systems are a default deny environment, but you are free to give away as much as you want to a program of your choice.
It's not the Internet switching fabric that is the problem, it's the end nodes. None of our PCs is provably secure. It's highly likely it won't be by 2020 either, as it appears the money is going into the wrong places in research. Capability Based Security has been around since the 1980s, and yet it's not even being funded to try to get it ready for widespread use by 2020.
Until the ends of the internet are secure, it's not going to be secure. It almost seems the money is always being spent in places where it won't really help the end user, but will allow more control by the authorities. (Or maybe I'm just a bit paranoid?)
Y2K was mostly a result of the radical shift in the nature of software development brought about by the IBM 360 and other computers which included a new feature of backward compatibility. Prior to that time it was safe to assume that programs would only live until they needed to be re-written to run on the next generation of computer. So as a result, we had many programs living well past retirement age. This then lead to a sane design decision from the 1950's getting us into trouble 40 years later.
Now we have a similar situation with Nukes. The Test Ban Treaty radically changed the nuclear weapons development environment, and as a result our nukes are now well past their retirement age. They were meant to be replaced, but haven't been.
It is important to note that in both cases, the eventual cost are still WELL below the development and other costs which were avoided.
I learned a lot from this video Sugar: The Bitter Truth wherein Robert H. Lustig, MD, UCSF Professor of Pediatrics in the Division of Endocrinology, explores the damage caused by sugary foods. He argues that fructose (too much) and fiber (not enough) appear to be cornerstones of the obesity epidemic through their effects on insulin.
One of the things I learned is that exercise can't possibly burn off the calories you need it to for most people. The real reason exercise works is that it decreases appetite, which then reduces calorie consumption, while increasing metabolism, and is a health negative feedback loop to help stabilize weight.
If you start exercising and keep your caloric intake equal, you're negating the feedback look, and you'll have to do a LOT of exercise to do.
I think that if you learn more about the whole system, you'll approach things from a different perspective, and you can reach reasonable goals instead of constant frustration.
Since we've been going at the Personal Computer for at least 30 years, and nobody has yet caught on to the power and potential of capability based security... there is at least one quantum leap of development left to make a small fortune off of... get busy folks!
If you have an OS which is secure... you only need one... and it just keeps working.
None of the widely used operating systems out there is secure. Until we embrace microkernels which have been proven to be secure, along with default usage of the object capability model, we'll never be safe.
It's possible to secure a computer to withstand the full force of the internet, even with normal users... but not with the code we have now.
Tannenbaum is right about microkernels... and Linus has reached the wrong conclusion.
Amen!
Yes... real-time collaborative editing is a very powerful tool... to dismiss the main feature of a product out of hand is unfair.
Actually, it's already been done, it's called Co-Word... and it's pretty cool.
Here's the Google tech talk about it from last year: http://www.youtube.com/watch?v=84zqbXUQIHc
I like SVN... but it's primary objects are specific versions of files, it does not deal with the changes between them as a primary object, but a means to get the primary object. When you have multiple authors, it's important to know who made what changes, and exactly what the changes were... the "Google Wave" approach is different in that each and every change is tracked, and those changes can be merged into bigger change sets if required... but the granularity is much finer and the authorship is always known.
This allows you to share a document and make multiple simultaneous changes, providing a structure to do so all the way up and down... this framework gives you a standard way to do things, that can then be expanded upon in a whole new set of ways.
Yes... this stuff could be done in a web forum... just like you could program everything in assembler... but it's more efficient in many ways to spend a little CPU time to make up for hours of developer time.
This framework will allow others to reach much, much farther and do things you can't even imagine doing via php/javascript.
Really? Wave allows multiple people to edit the same document at the same time, across company lines... AFIK, this is not anywhere on the radar at Microsoft.
The basic problem these days is that you have many people who want to have access to a shared document. The solution that Microsoft was pursuing was good, and attempted to fit the RSS model blogs use to push content. But in the end you still have many copies of documents, and you're always trying to keep changes synced across them. This approach breaks down when you have multiple sources of change... conflict resolution will always jump up to bite you.
Google Wave is a brilliant leapfrog over this problem, at the cost of some complexity. They made engineering choices that so far seem to be very pragmatic and practical... and if you don't like them you could always build your own. They actually distribute the changes to all observers, using OT (Operational Transforms) to keep everything synchronized. As a benefit, you can work on only the changes to a document, instead of having to re-scan the whole thing every time something changes, to attempt to work backwards to figure out the changes.
The ambition of Google's approach is backed up with a brilliant exploration of the solution space, and a very good choice of models, both in terms of the open source approach, in their openness with documentation, etc... and their choice of federation as a first class part of the model.
The latest analogy that I came up with is one of a Jet Engine.... instead of working on one charge of fuel/air at a time (one document)... it operates on a stream of fuel and air.... which allows for higher performance (at the cost of some fuel efficiency).
We don't care as much about the computational cycles as we do all the human time this saves by tracking all the changes, and who made them.
Bravo, Google... you've done it again!
Slashdot sucks when it's time to try to actually learn something instead of flaming and ranting and trying to one-up each other.
The principle of least privilege is the only known approach that might possibly lead to a secure operating system... what do we do in the US? Let the only project we have fall off into obscurity.
We then deride the EU when they actually decided it would be a good idea to try to fund a project with the possibility of success.
We need secure endpoints before we can ever hope to have a secure infrastructure. We're not smart enough to even try to pursue the only known approach that might work. We're doomed. Hopefully someone will understand this, not see it as a pure rant, and learn something.
--Mike--
Yes, covert channels will always be an issue, as with physical security... but I think we can agree that specifying the capabilities to be given to a piece of code is a much saner way to do things than to be forced to trust your code.
Until we get operating systems that can run code without having to trust it, we're going to keep getting the same crap, over and over.
Linux isn't the answer. Hell, even SElinux isn't the answer.
Start reading up on Eros, Keykos and Capros to see about systems that might actually solve the security issues once and for all.
Get a bunch of $300 Acer Aspire One netbooks, each with WiFi, 1 GB RAM, 120 GB Hard drive, and distribute the work...
I think that 50 of them would be pretty quick in a Beowolf cluster. (Well... an XP gaggle... but I digress)
The problem is that we've optimized on the wrong thing, programming convenience, instead of user productivity. Computers are supposed to be a tool for humans to better manipulate symbols and information. There's no reason not to keep all of the input received via the keyboard or mouse from the user along with the context... it's tiny... a few bytes per hit, without compression. Saving the internal deltas of almost anything a typical user does with a PC are not unreasonable.
--Mike--
CoFounder - KillSave.org