Slashdot Mirror

This is a description of Sutherland's Wheel of Reincarnation. Many have observed that it applies to (among other things) client-server computing as well.

Before anyone jumps on the band wagon and says that we all have perfectly usable user space desktop apps for 28 years in the UNIX world, let me say that it is actually very important that now even Microsoft starts to understand that modularity is the way to go while designing complex systems. Moving various operating system components to the user space is just a logical conclusion of the research done during the last four decades. Look at the direction of modern OSii development, from MINIX to GNU. Started by GNOSIS, KeyKOS, EROS and Coyotos this trend seems to suggest that it is much more natural and reliable to design a secure capability-based system when all of the services are separated from each other. Now when even Microsoft is going in that direction - and it is not a trivial change for them, trust me - we can expect Apple and other OS vendors to follow which is a Good Thing. After all, even if people like you and me are using secure operating systems we still don't want to get spammed and dossed by all of the legacy machines out there. It turns out that the rumors that Microsoft is starting to take the latest research in operating systems seriously turned out to be true. This is good news for everyone.

And the wheel of reincarnation turns another step.

And so the wheel of reincarnation turns another notch...

This is clearly an institutional problem. The technical solutions proposed here are part of the solution but you need an institution to store your data and need that institution to have a adequate incentive and financial means to really keep it. Here is a long and complex description of such an institution: http://cap-lore.com/BigStore/DataBank.html . I have 100 year old photographs. I think the data bank would likely keep your bits that long. I wish someone would steal my idea!

See Ivan Sutherland's Wheel of Reincarnation. The idea is that CPUs get faster and graphics move there; then busses get faster and graphics moves to dedicated hardware; rinse and repeat. http://www.anvari.org/fortune/Miscellaneous_Collections/56341_cycle-of-reincarnation-coined-by-ivan-sutherland-ca.html

There is a rule in security: "Don't Prohibit what you can't Prevent" [1]. The same rule applies to laws.

http://www.cap-lore.com/Hardware/Wheel.html

Just another step in the well known Wheel of Reincarnation. At least well known to all three of us who don't completely ignore computer history ;-)

Net neutrality just means that providers route packets based on the RFCs, which means no degredation or enhancement of service unless the IP protocol specifies that this MUST, SHOULD or MAY happen.

Yes, IP is best effort.

In other words, route the packets from source to destination, applying QoS based on the Type of Service in the IP header.

To my knowledge, no one uses the TOS bit. QoS is best done with a more advance protocol such as RSVP http://www.cap-lore.com/Nets/RSVP.html. I only bring up RSVP because it is available to me as a programmer using specific WSAIoctl() calls on a socket. This, of course, assumes the route is RSVP enabled.

Specifically, net neutrality must prevent ISPs from charging third parties for routing IP traffic.

Yes, ISPs want the triple dip! We know this is wrong and against the agreements they have with their backbone providers.

Only directly connected peers should be part of the contract, because the IP protocol does not allow the sender of a packet to specify which hosts the packet will travel through, and thus there is absolutely nothing to base a contract on, unless the source or destination address of the packet belongs to one of the ISPs networks.

You can set a strict source route. It is an IP option. Any good firewalls look at that as suspicious for a man-in-the-middle attack. I'm not sure how that even behaves these days, but I understand what you mean. Once you've left your QoS path, all bets are off and you're back to best effort.

Since IP has QoS built in, it's obviously a good thing, and not the terrible Tiered Internet that people are afraid of.

The TOS bit isn't used. See RSVP http://www.cap-lore.com/Nets/RSVP.html.

QoS just means that some packets will have priority over others. It doesn't say that some protocols or destinations or sources of IP packets will have that priority, just the ones with certain types of service.

Ok, I hear ya. Even though I wanted to look at this originally as a technical issue inside a "political" one, it really just is a "political" battle for the ISPs and backbone providers wanting a triple dip payoff.

Anyone should be able to buy higher classes of service for their packets, and put whatever they want inside those packets. That's net neutrality, because it favors decisions at the endpoints of the Internet instead of the middle.

Agreed.

Net neutrality just means that providers route packets based on the RFCs, which means no degredation or enhancement of service unless the IP protocol specifies that this MUST, SHOULD or MAY happen.

Yes, IP is best effort.

In other words, route the packets from source to destination, applying QoS based on the Type of Service in the IP header.

To my knowledge, no one uses the TOS bit. QoS is best done with a more advance protocol such as RSVP http://www.cap-lore.com/Nets/RSVP.html. I only bring up RSVP because it is available to me as a programmer using specific WSAIoctl() calls on a socket. This, of course, assumes the route is RSVP enabled.

Specifically, net neutrality must prevent ISPs from charging third parties for routing IP traffic.

Yes, ISPs want the triple dip! We know this is wrong and against the agreements they have with their backbone providers.

Only directly connected peers should be part of the contract, because the IP protocol does not allow the sender of a packet to specify which hosts the packet will travel through, and thus there is absolutely nothing to base a contract on, unless the source or destination address of the packet belongs to one of the ISPs networks.

You can set a strict source route. It is an IP option. Any good firewalls look at that as suspicious for a man-in-the-middle attack. I'm not sure how that even behaves these days, but I understand what you mean. Once you've left your QoS path, all bets are off and you're back to best effort.

Since IP has QoS built in, it's obviously a good thing, and not the terrible Tiered Internet that people are afraid of.

The TOS bit isn't used. See RSVP http://www.cap-lore.com/Nets/RSVP.html.

QoS just means that some packets will have priority over others. It doesn't say that some protocols or destinations or sources of IP packets will have that priority, just the ones with certain types of service.

Ok, I hear ya. Even though I wanted to look at this originally as a technical issue inside a "political" one, it really just is a "political" battle for the ISPs and backbone providers wanting a triple dip payoff.

Anyone should be able to buy higher classes of service for their packets, and put whatever they want inside those packets. That's net neutrality, because it favors decisions at the endpoints of the Internet instead of the middle.

Agreed.

This sounds a lot like Capabilities http://www.cap-lore.com/CapTheory/, though it appears that Microsoft gave it a new name (it's also hard to Google on just 'capabilities' as all you get are marketing fluff sites rather than Capabilities).

I think some of this is already in various UNIX and Linux distributions in the form of NSA SELinux and other similar systems. Applications have a set of operations defined that they can do while restricting or denying access to other operations, which is pretty much the same thing as the manifest that Microsoft describes.

I need to dig deeper into the SELinux that's built into my Fedora Core boxes. I'd imagine that if Microsoft actually puts this into Longhorn, general interest in SELinux will also increase.

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

A quick search on KeyKOS makes one wonder: Does it have anything in common with GNU's microkernel efforts? Anyone cares to post a brief overview of KeyKOS, possibly in connection and/or comparison to Mach/HURD?

Short answer: yes it does, and it is actually one of the main reasons why I look forward to use Debian GNU/Hurd in the future. Let me quote my old post from January with some background and interesting links to more informations about KeyKOS:

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

And here is a newer post of mine asking exactly your question about KeyKOS capabilities in connection to the recent development of The Hurd, in the First Program Executed on L4 Port of GNU/HURD discussion two months ago:

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security fe

Longhorn will be the first release of Windows authored completely after Microsoft began their Trusted Computing Initiative and released .NET. Longhorn will reimplement and convert major Windows subsystems to managed code.

This really starts to get boring. I have already written about it countless times only to get completely ignored every time I dare to point out that the emperor is naked.

I find it truly amusing that people who say that there are other advantages than only Digital Restrictions Management of using "trusted" computing and Palladium-like platforms usually talk with great enthusiasm and excitement about the new and innovative security features that have already been implemented in the 1970s for crying out loud, only better and with no strings attached. All TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness for God's sake and without all of the silliness of "trusted" computing.

And no, this is not only my opinion that we don't need DRM to get security. I am not the only one who says that everything that TCPA can possibly do to security can also be done in software, with the only exception of DRM, and in fact it has already been done, decades ago. I am not really surprised at all why it is completely ignored by the TCPA and TCI pushing industry. I am only outraged that there are so many naïve people who once again will gladly do anything no matter how dumb it is, if only their good uncle Bill Gates says that it's good for them.

Please, people, if you want to learn about real systems security, then read some old papers by Jerome Saltzer, Michael Schroeder, Norman Hardy and Jonathan Shapiro. If you want to learn about cryptography, read texts by Bruce Schneier. Microsoft is not a reliable source of knowledge in that field.

People always ask me where are the real innovations in systems security and I always say them that they are in the seventies, and have been being ingnored since then by major software vendors because people don't demand using them. This story and this thread is a great example: "Yeah, this version of Windows may suck, but still I am looking forward to buy the next one."

This will dramatically lessen the exploitation potential of code flaws in the Windows application libraries. Microsoft has to maintain support for legacy application, but that doesn't mean they can't get a fresh start on the underlying code, and doesn't mean that existing Microsoft applications can't be converted to managed code as well.

Wait, I've already heard it... In 1995, 1998, 2000, 2003... Oh, you mean that this time they really mean it?

Longhorn will be the first release of Windows authored completely after Microsoft began their Trusted Computing Initiative and released .NET. Longhorn will reimplement and convert major Windows subsystems to managed code.

This really starts to get boring. I have already written about it countless times only to get completely ignored every time I dare to point out that the emperor is naked.

I find it truly amusing that people who say that there are other advantages than only Digital Restrictions Management of using "trusted" computing and Palladium-like platforms usually talk with great enthusiasm and excitement about the new and innovative security features that have already been implemented in the 1970s for crying out loud, only better and with no strings attached. All TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness for God's sake and without all of the silliness of "trusted" computing.

And no, this is not only my opinion that we don't need DRM to get security. I am not the only one who says that everything that TCPA can possibly do to security can also be done in software, with the only exception of DRM, and in fact it has already been done, decades ago. I am not really surprised at all why it is completely ignored by the TCPA and TCI pushing industry. I am only outraged that there are so many naïve people who once again will gladly do anything no matter how dumb it is, if only their good uncle Bill Gates says that it's good for them.

Please, people, if you want to learn about real systems security, then read some old papers by Jerome Saltzer, Michael Schroeder, Norman Hardy and Jonathan Shapiro. If you want to learn about cryptography, read texts by Bruce Schneier. Microsoft is not a reliable source of knowledge in that field.

People always ask me where are the real innovations in systems security and I always say them that they are in the seventies, and have been being ingnored since then by major software vendors because people don't demand using them. This story and this thread is a great example: "Yeah, this version of Windows may suck, but still I am looking forward to buy the next one."

This will dramatically lessen the exploitation potential of code flaws in the Windows application libraries. Microsoft has to maintain support for legacy application, but that doesn't mean they can't get a fresh start on the underlying code, and doesn't mean that existing Microsoft applications can't be converted to managed code as well.

Wait, I've already heard it... In 1995, 1998, 2000, 2003... Oh, you mean that this time they really mean it?

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?

When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?

a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root.

This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS?

Linux? Kids these days... Capabilities is a feature from the 1970s. If Coyotos is anything like EROS or KeyKOS, then they don't mean POSIX "capabilities" but real capabilities as described in 1975 by Jerome Saltzer and Michael Schroeder in the famous The Protection of Information in Computer Systems paper: "Capability--In a computer system, an unforgeable ticket, which when presented can be taken as incontestable proof that the presenter is authorized to have access to the object named in the ticket." For an excellent introduction to capabilities, read What is a Capability, Anyway? by Jonathan Shapiro. Then read the Capability Theory by Sound Bytes essays by Norman Hardy for more informations. Those papers are classics, just like Reflections on Trusting Trust by Ken Thompson. It's a must-read for anyone who wants to have even the slightest idea about computer security at all.

a project to create an operating system whose security relied on capabilities rather than the traditional Unix model of root or non-root.

This has been possible in Linux (and some proprietary Unices) for some time now. Why the need for a separate OS?

Linux? Kids these days... Capabilities is a feature from the 1970s. If Coyotos is anything like EROS or KeyKOS, then they don't mean POSIX "capabilities" but real capabilities as described in 1975 by Jerome Saltzer and Michael Schroeder in the famous The Protection of Information in Computer Systems paper: "Capability--In a computer system, an unforgeable ticket, which when presented can be taken as incontestable proof that the presenter is authorized to have access to the object named in the ticket." For an excellent introduction to capabilities, read What is a Capability, Anyway? by Jonathan Shapiro. Then read the Capability Theory by Sound Bytes essays by Norman Hardy for more informations. Those papers are classics, just like Reflections on Trusting Trust by Ken Thompson. It's a must-read for anyone who wants to have even the slightest idea about computer security at all.

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

Still, you can't block every hole in security. Sometimes you just have to hope, right?

Yes, you can. No you don't. Software is just an applied form of discrete mathematics. "Beware of bugs in the above code; I have only proved it correct, not tried it," as Donald Knuth once said. It is possible to present a formal proof of correctness for any algorithm. It is nearly impossible and certainly impractical when you have a big mess of spaghetti code like with most of software that is utter crap, but it is possible nonetheless when you know what are you doing and design appropriately, with very clean, small and isolated parts of your system responsible for enforcing its security policies. Take a look at such operating systems as KeyKOS and EROS. E.g. read Verifying Operating System Security paper by J. S. Shapiro and S. Weber: "This paper presents a proof of correctness of the EROS operating system architecture with respect to confinement." Read some essays by Norman Hardy, especially those on Capability Theory. This is hardly a new idea, see GNOSIS: A Prototype Operating System for the 1990s paper by Bill Frantz, Norm Hardy, Jay Jonekait and Charlie Landau, written more than 25 years ago. The bottom line is: it is certainly possible to have a 100% secure system, but developers don't bother because users don't care.

To summarize: the traditional access controls are designed to protect users from each other. This is not enough.

What you need is a capability based system. And by capabilities I don't mean POSIX "capabilities" but the real ones. This is hardly a new idea. Read some papers by Norman Hardy. Start from Capability Theory by Sound Bytes and read the referenced articles until you start getting the idea. Then read about GNOSIS: A Prototype Operating System for the 1990s, a 1979 paper by Bill Frantz, Norman Hardy, Jay Jonekait and Charlie Landau. Then read about KeyKOS, a persistent, pure capability operating system. Then read about EROS: The Extremely Reliable Operating System. I think it will be enough for a good start. As you see all of those problems we discuss today in this article have already been solved in the '70s or '80s at worst. But those who don't know the history are doomed to repeat it.

To summarize: the traditional access controls are designed to protect users from each other. This is not enough.

What you need is a capability based system. And by capabilities I don't mean POSIX "capabilities" but the real ones. This is hardly a new idea. Read some papers by Norman Hardy. Start from Capability Theory by Sound Bytes and read the referenced articles until you start getting the idea. Then read about GNOSIS: A Prototype Operating System for the 1990s, a 1979 paper by Bill Frantz, Norman Hardy, Jay Jonekait and Charlie Landau. Then read about KeyKOS, a persistent, pure capability operating system. Then read about EROS: The Extremely Reliable Operating System. I think it will be enough for a good start. As you see all of those problems we discuss today in this article have already been solved in the '70s or '80s at worst. But those who don't know the history are doomed to repeat it.

This phenomenon is commonly known as the "Wheel of Reincarnation". Diverting functionality to specialized components, and then folding it back onto the CPU has been going on since the 60s.

A more detailed description of the WoR is available here.

ACLs are probably not even a part of any secure solution, and are not very useful for secure computing. That when comparing them to capabilities.

POSIX has done a very bad service to the computing world by defining the term POSIX capability contraductory to the original term.

POSIX capabilities are more like ACLs than real capabilities.

It would be great if we could chuck the whole user-based system in favor of some sort of role or program-based model where programs have privileges based on what they are rather than who is running them.

In fact, that's a core concept of the capability security model: "There is no fundamental reason why a program that you write for me should be able to delete my bank transactions file just because I can. Yet those are the permission rules imposed by the current commercial OSes for personal systems."

More here.

Aloha!

You wrote: My question - If these cards are getting so powerful at computations then why do we need a Intel/AMD processor at all? Just make a graphics card with more transistors and drop the traditional processor...

Congratulations! You have just reinvented Ivan Sutherlands Wheel of reincarnation which is exactly about this: Normal CPU:s are enhanced with specific functions to provide acceleration for a common task, the enhancments are getting so big that farming them out into a separate chip/module seems like a good idea. The separate thingy grows in complexity as more flexilibility and programmability is needed. Finally you end up with a new CPU. And then someone says.... You get the idea.

Here is a good take on Ivan Sutherlands story. And here is Myers and Sutherlands original paper.

Read, think and learn.

Unnatural Monopoly: Critical Moments in The Development of The Bell System Monopy

Later decided that they changed their minds and broke it up, and this is supposed to give me some faith that government can do good? What about all the damage government did to telecommunications in the mean time? (The Bell monopoly was enforced by the SSSCA's of its day. There was a time when you needed AT&T's permission to hook up a modem The Origins of Tymnet.)

I should point out that I am not an anarchist, protecting people from fraud is one of the police functions that a government should do. However, just because government occaisionally does it's proper job doesn't mean I want it to expand into other areas like controlling what I eat, drink, read, write, and spend money on.

For every good use of government, it seems, they throw up an SSSCA or DMCA. Be aware of the government's culpability in the whole Enron fiasco, Myths About Enron, which they have managed to successfully hide in most of the mainstream media.

If anything Unix needs to push it over the top as far as a secure server operating systems is the ability to tell the OS that "This File can never be deleted and can only be appended to by ...

More importantly, I think UNIX needs a better security model. Right now one of the big problems is that all of your executables have the same permissions that you do. In a capability based system, your email program may own capabilities for reading its configuration files, but an open() on a file owned by the user would require active user input to succeed. (Someone wrote a paper about using a Windows-like GUI to make capabities more understandable to the user, but I can't find the url at the moment.)

In any case, here are some links.
"E", a capability-secure language.
Capabilitiesvs. Microsoft's signed execuatables solution. (Part of a good introduction to capabilities).
Linux Kernel Capabilities vs. the standard definition of capabilities.

Capabilities rock my world and provide the capability (pun not intended) for the sort of no-nonsense secure-by-default security that people dream of these days. I don't know how effectively they can be added to the linux platform in general, since we have a lot of existing software that could break given a sufficiently odd change to the general security model. But, capabilities are a good start for creating and maintaining a secure-by-default future for Linux. Pervasive use of capabilities would make me very happy, since then I might actually have some control over what programs will actually be allowed to DO!

relevant capabilities link