.NET and Java are both insecure, because they both rely on too much code written in unsafe languages.
If you want to implement a system based on language-level security using a mixture of code in safe and unsafe languages, as little as possible of the system must be written in the unsafe language(s), and that part must be treated as being in the system TCB.
Some unsafe code is unavoidable if you want the system to be able to use OS facilities on Windows and Unix. However, it must be written by people who know how to write secure code, and gone over with a fine-tooth comb for possible weaknesses.
It is completely disingenuous for either Microsoft or Sun to claim that these platforms are secure, given that their implementations depend on millions of lines of unsafe-language code that no-one is ever going to review properly. Even more so since both.NET and Java allow any arbitrary application to load unsafe code.
So basically, Gosling's argument is correct:.NET will never be secure with its current architecture. Neither will Java. I am personally convinced that language-based security can be made to work (using a capability security model), but not the way Microsoft or Sun are doing it.
Persistence was one of the things in EROS (and earlier in KeyKOS) that was completely implemented and worked fine. It is not difficult to implement, especially for people who have experience of checkpointing algorithms from two previous systems.
Nothing about orthogonal persistence stops you from taking a "conventional" approach to persistence (or a hybrid approach) in any particular application. Also Coyotos will have a Linux compatibility layer, which should help to get over the initial application compatibility hurdle.
Finally, having persistence built-in *is* the right thing to do for a capability system, since it minimizes the overall complexity of restoring the security state.
There is a discussion on coyotos-dev at the moment about the decision to remove persistence; it's entirely possible that it will be reversed. Subscribe if you have an interest in this (but read the archive of the thread first).
Slashdot Mirror
.NET and Java are both insecure, because they both rely on too much code written in unsafe languages.
.NET and Java allow any arbitrary application to load unsafe code.
.NET will never be secure with its current architecture. Neither will Java. I am personally convinced that language-based security can be made to work (using a capability security model), but not the way Microsoft or Sun are doing it.
If you want to implement a system based on language-level security using a mixture of code in safe and unsafe languages, as little as possible of the system must be written in the unsafe language(s), and that part must be treated as being in the system TCB.
Some unsafe code is unavoidable if you want the system to be able to use OS facilities on Windows and Unix. However, it must be written by people who know how to write secure code, and gone over with a fine-tooth comb for possible weaknesses.
It is completely disingenuous for either Microsoft or Sun to claim that these platforms are secure, given that their implementations depend on millions of lines of unsafe-language code that no-one is ever going to review properly. Even more so since both
So basically, Gosling's argument is correct:
Persistence was one of the things in EROS (and earlier in KeyKOS) that was completely implemented and worked fine. It is not difficult to implement, especially for people who have experience of checkpointing algorithms from two previous systems.
Nothing about orthogonal persistence stops you from taking a "conventional" approach to persistence (or a hybrid approach) in any particular application. Also Coyotos will have a Linux compatibility layer, which should help to get over the initial application compatibility hurdle.
Finally, having persistence built-in *is* the right thing to do for a capability system, since it minimizes the overall complexity of restoring the security state.
There is a discussion on coyotos-dev at the moment about the decision to remove persistence; it's entirely possible that it will be reversed. Subscribe if you have an interest in this (but read the archive of the thread first).