C# vs Sun Java security

  • Thread starter Thread starter Mario
  • Start date Start date
M

Mario

I've been reading some Sun Java articles where they say
Applets cannot import dlls and cannot write to disk.
(This does NOT apply to applications, only to Applets.)
Supposedly, this is NOT something you can cotrol with a
security manager or in any other way. The dll exclussion
is due to the fact that the virtual machine cannot
control what a dll is doing, perhaps writting malicious
stuff to disk among other things. Is it true that Applets
cannot write to disk and import dlls?

Since C# is the "equivalent" of java, are there any
restrictions on disk write and dll inclussion? If so, can
they be controlled in some way, or thay are like, what I
understood for Sun Java, set in stone as impossible to do.
By the way, what is the equivalent in C# of the Applet
concept in Java?

Greetings,
Mario
 
Mario said:
I've been reading some Sun Java articles where they say
Applets cannot import dlls and cannot write to disk.
(This does NOT apply to applications, only to Applets.)
Supposedly, this is NOT something you can cotrol with a
security manager or in any other way. The dll exclussion
is due to the fact that the virtual machine cannot
control what a dll is doing, perhaps writting malicious
stuff to disk among other things. Is it true that Applets
cannot write to disk and import dlls?
Click to expand...

Java applets run in a "sandbox" - a managed environment that disallows
certain actions considered to be unsafe, as you point out.
By default, applets cannot write to disk or use a native interface. I used
to teach Java classes at the local university, but I've become increasingly
disallusioned with it and Sun and pretty much gave up on it, so I don't know
if they updated this behavior or not.
Since C# is the "equivalent" of java,
Click to expand...

I don't really consider that to be true. There may be a lot of similarities,
but the architectural and phylosophical core of each is quite different.
are there any
restrictions on disk write and dll inclussion? If so, can
they be controlled in some way, or thay are like, what I
understood for Sun Java, set in stone as impossible to do.
By the way, what is the equivalent in C# of the Applet
concept in Java?
Click to expand...

There is no real equivalent to applets in C#. Stuffing a crippled window
inside a browser is a rather lame way of presenting an application. Instead,
..NET allows you to run entire applications from the internet. When any .NET
application is executed, the runtime environment inspects certain aspects of
the application (evidence) - such as where it is run from, who created it,
etc. Based on this evidence, the .NET environment assigns allowable
operations to the code, and prevents the code from running things that it
shouldn't. For example, by default, applications that run from the internet
(for example, if you run a .NET exe from an internet URL) cannot write to
disk except for a limited data area created especially for this purpose, and
they also can't execute unmanaged code (code from non-.NET dlls). As a user
(or more accurately, an administrator of a system), you have full control
over these security settings. You can, for example, set that any application
that comes from Microsoft (it will have a special Microsoft signature) is
allowed to do anything it wants to do, even if it is run from the internet.

Look in the documentation or the MSDN web site for .NET code access
permissions and security. There's a ton of material on it.

-Rob Teixeira [MVP]
 
The only way I know of making Java applets write to
disk and using native methods is if the applet is run by
a java applet viewer.

The articles I was reading were saying not only that by
default applets cannot write to disk and call native
methods, but there is NOTHING one could do to the Applet
Security Manager to change this. This is in contrast to
C#, where as you point out, the administrator could
enable disk write and dll use.

Thanks,
Mario
 
Mario said:
The only way I know of making Java applets write to
disk and using native methods is if the applet is run by
a java applet viewer.

The articles I was reading were saying not only that by
default applets cannot write to disk and call native
methods, but there is NOTHING one could do to the Applet
Security Manager to change this.
Click to expand...

I don't believe this is true - apart from anything else, if you sign
your applets and the user accepts your certificate, you can do pretty
much anything, I believe.
 
I could, but it would occupy many page ;-)
In summary, it became very apparent that Sun was far more interested in
selling hardware and chips than it was in Java. In fact, Java appears from
there perspective to be little more than a freebie tossed out to the IT
community to help promote said hardware and chips. I dare say that companies
like IBM and BEA have done far more for Java than Sun has. This conclusion
has come out of years of disappointments, undelivered hype, and quite a bit
of hypocracy concerning competitor products and behavior - plus a rather
shaky and double-sided stance on things non-hardware-related - take Linux,
for example. Jim Fawcette had an interesting article (blog?) along these
lines http://www.ftponline.com/weblogger/forum.aspx?ID=1&DATE=12/12/2003 not
too long ago.

However, what bothers me the most about the language, is the underlying
principal that it sacrifices native rources in favor of
lowest-common-denominator features allowing it to be a
write-once-run-everywhere language, which in reallity, isn't entirely true
to begin with. This was a common theme sprinkled throught the language
architecture. Take Java's native interface as an example - you had to write
C++ code that conformed to Java's standard, when in reality, what we REALLY
needed was the ability to interface with EXISTING C++ code - and this is
exactly what P/Invoke and .NET interop allowed from the beginning.

Anyway, considering this is a C# forum, I'll have to try to keep the focus
on that instead of berating some company. I don't want this to become my
rant-blog/soapbox :-)

-Rob Teixeira [MVP]
 
Back
Top