Slashdot Mirror


Don Box: Huge Security Holes in Solaris, JVM

DaHat writes "Don Box, one of the authors of the original SOAP specification in 1998, now an architect on Microsoft's next generation Indigo platform recently responded to James Gosling's remarks regarding huge security holes within the .NET Common Language Runtime (CLR). Don argues that the same 'flaws' that Gosling noted in the .NET CLR exist both within the Solaris operating system as well as the JVM, both of which support execution of C and C++ code, as well as explaining why this is not necessarily a bad thing."

2 of 226 comments (clear)

  1. Why "managed" == "denial" by Concern · · Score: 5, Insightful

    When .NET was first announced and the details began to be known, there were a number of lively discussions here about it. The "feature" of running unmanaged code was hotly debated, but the debate seemed to me to be entirely one-sided. It seemed clear unmanaged code is another classic Microsoft mistake - trading sugary convenience today for billions in headaches for their customers tomorrow. I went looking for someone to convince me otherwise and didn't succeed. Maybe now?

    There is great value in a "managed" system like the Java VM. It gives us an extraordinary amount of safety that we are frankly unaccustomed to. People are still gradually learning how to think about it, but you see more and more security-critical projects going "Java only" as they figure it out.

    There is also obviously no way we can do everything that way. For hot code, we work at lower levels, put in more work, and (for now) accept the additional risks. Note that the constant stream of ugly worldwide security problems is gradually but now noticeably decreasing our apetite for doing everything that way.

    As far as I can tell, by allowing unmanaged code in the runtime, .NET gives you only the worst of both worlds.

    You get all the overhead of the VM, but you don't really get safety.

    I know perfectly well you can tell the .NET runtime not to allow unmanaged code. That doesn't matter, because the choice is there, "unmanaged" is still a huge problem.

    Either it is avoided by everyone (everyone recognizes that it's a mistake), or we all begin to use it (it's in XYZ library), and then we all end up allowing unmanaged code, and we are no longer safe.

    --
    Tired of Political Trolls? Opt Out!
  2. Re:JNI is an API, not a platform... by jeif1k · · Score: 4, Insightful

    JVM - no, that's safe. JNI is an API, not a platform.

    You can look at C# as two languages: an "unsafe" and a "safe" language. The safe language is the equivalent of Java. The "unsafe" language is the equivalent of C or C++ linked in through JNI. Linking "unsafe" to "safe" code in C# has the same restrictions on it as does linking native code to pure Java code in Java. So, Gosling's rantings have no technical merit.

    However, the C# solution is better than the Java solution: unsafe code in C# still contains substantially more error checking than equivalent C code linked through JNI, you generally need much less unsafe code in C# than in Java to accomplish the same task, and C# unsafe code doesn't need to be recompiled for different platforms and can just be distributed like other C# code.

    Don's comments did not really add anything that wasn't covered in the Slashdot discussion.

    What do you want? He is responding to an enormously stupid, self-serving comment from Gosling. You have to be clear and keep things simple in order to reach the kind of people who would swallow Gosling's nonsense in the first place.