C# vs Sun Java security

[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

[Rob Teixeira [MVP]]

"Mario" <an*******@discussions.microsoft.com> wrote in message
news:04****************************@phx.gbl...

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?
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,
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?
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]
Greetings,
Mario

[Mario]

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

-----Original Message-----
"Mario" <an*******@discussions.microsoft.com> wrote in messagenews:04****************************@phx.gbl...

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?
Java applets run in a "sandbox" - a managed environment

that disallowscertain actions considered to be unsafe, as you point out.By default, applets cannot write to disk or use a native interface. I usedto teach Java classes at the local university, but I've become increasinglydisallusioned with it and Sun and pretty much gave up on it, so I don't knowif they updated this behavior or not.

Since C# is the "equivalent" of java,
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?
There is no real equivalent to applets in C#. Stuffing a

crippled windowinside a browser is a rather lame way of presenting an application. Instead,..NET allows you to run entire applications from the internet. When any .NETapplication is executed, the runtime environment inspects certain aspects ofthe application (evidence) - such as where it is run from, who created it,etc. Based on this evidence, the .NET environment assigns allowableoperations to the code, and prevents the code from running things that itshouldn'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 todisk except for a limited data area created especially for this purpose, andthey 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 controlover these security settings. You can, for example, set that any applicationthat comes from Microsoft (it will have a special Microsoft signature) isallowed 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 accesspermissions and security. There's a ton of material on it.
-Rob Teixeira [MVP]

Greetings,
Mario

.

[Alvin Bruney]

>but I've become increasingly

disallusioned with it and Sun and pretty much gave up on it Interesting. Would you care to explain this?

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... "Mario" <an*******@discussions.microsoft.com> wrote in message
news:04****************************@phx.gbl...

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?
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,
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?
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]

Greetings,
Mario

[Jon Skeet [C# MVP]]

Mario <an*******@discussions.microsoft.com> wrote:

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Rob Teixeira [MVP]]

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/f...ATE=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]

"Alvin Bruney" <vapor at steaming post office> wrote in message
news:en**************@TK2MSFTNGP11.phx.gbl...

but I've become increasingly
disallusioned with it and Sun and pretty much gave up on it

Interesting. Would you care to explain this?

[William Ryan]

BTW, Code Project just put up a pretty good article on COde Access
Security... http://www.codeproject.com/dotnet/UB_CAS_NET.asp
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"Mario" <an*******@discussions.microsoft.com> wrote in message
news:04****************************@phx.gbl...

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?
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,
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?
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]

Greetings,
Mario

[Alvin Bruney]

great article

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/2bz4t
"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2******************@TK2MSFTNGP12.phx.gbl...

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/f...ATE=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]

"Alvin Bruney" <vapor at steaming post office> wrote in message
news:en**************@TK2MSFTNGP11.phx.gbl...

but I've become increasingly
disallusioned with it and Sun and pretty much gave up on it

Interesting. Would you care to explain this?