Java vs. .NET Security, Part 1
Subject:   Corrections & clarifications
Date:   2004-07-09 13:10:46
From:   rayburns
Two notes:

1. The author is mistaken about being unable to run different applications with different security policies in .NET. The Java and .NET designers took different approaches here:

* In Java you have a variety of security policy files and specify which one to use as you start the application.
* In .NET you have a single security policy file at each level (Enterprise, Machine, User) which gives the general rules and the exceptions on a per-application basis. So for example you can specify that this application can access certain files but other applications can't. The security configuration files can be easily be shared among machines to keep a consistent security model across the enterprise.

The main difference here is that in Java the actual security you get depends on the command line you use to start an application. In .NET the security is unaffected by the command line, making it easier to be sure you're getting the security level you require.

2. The reason Java needs to preserve the bytecode stack for runtime checks is due to a flaw in the design of the JVM which renders it difficult to verify without doing so. The designers of .NET learned from the Java's problems and defined IL in a slightly different way that makes it unnecessary to incur the extra overhead of an extra runtime stack.

Ray Burns

Full Threads Newest First

Showing messages 1 through 1 of 1.

  • Corrections & clarifications
    2004-07-09 13:39:25  dpiliptchouk [View]

    Answering by items:

    1. Yes, you can modify a policy to grant/deny access by application's features (like strong name). HOWEVER: if one application relies on LocalComputer code group having FullTrust, and another application wants to reduce it to Everything, there's no way in .NET to resolve this conflict - exactly because of the shared policies. As for the conclusion - I guess, that's the difference in approaches, because I view Java's ability to control security policies via command-line switches as a significant advantage, rather than as a drawback, as was implied in the posting.

    2. As for the bytecode - even though Java had issues with runtime checks, this approach reflects the architectural difference, rather than simply workaround for a bug.