Hi

This issue is documened at
http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx#0000
0153 (Secure Serialization in .NET Remoting -  ackwards Breaking Changes
from version 1.0 to 1.1)

A level of security has been added to Serialization.  Specifically, there
are now two levels of serialization security: Low (Default) and Full.

Low Level Security:
? Remoting infrastructure objects. These are the types needed to make
remoting work at a basic level.
? Primitive types, and reference and value types that are composed of
primitive types.
? Reference and value types that are marked with the SerializableAttribute
attribute but do not implement the ISerializable interface.
? System-provided types that implement ISerializable with a reduced
permission set.

? Custom types that implement ISerializable.
? Types that implement the ILease interface.
? ObjRef objects used for activation (to support client-activated objects).

Full Level Security:
? ObjRef objects passed as parameters.
? Objects that implement the ISponsor interface.
? Objects that are inserted between the proxy and client pipeline by the
IContributeEnvoySink interface.

MORE INFORMATION:

In version 1.1 of the .Net Framework, a new security feature was added to
the .Net Remoting infrastructure called Type Filtering. This feature, which
is enabled by default, limits the type of objects that may be marshaled by
a Remoting client to a Remoting server. Type Filtering effectively
prohibits the server from deserializing instances of CLR types that may
serve as vectors of attack. This feature is part of Microsoft¡¯s commitment
to be secure by default.
The following outlines several of the threats that are mitigated by use of
this feature (we are not going to give out details about how to exploit
these threats), specifically when typeFilterLevel is set to Low:

Exposing a Remoting server with a method or member that takes a delegate.
Threat: Delegates may be used to invoke methods on other types that have
the same signature

Exposing a Remoting server with a method or member that takes a
MarshalByRefObject type. Threat: The serialized form of a
MarshalByRefObject contains a mutable URL

Exposing a Remoting server with a method or member that takes an
ISerializable type.
Threat: Deserialization of an ISerializable type causes the Remoting
infrastructure to run the type¡¯s code.

Exposing a Remoting server with a method or member that takes an type found
in the GAC on the server machine in an assembly without APTCA
Threat: Types in the GAC are well known to anyone with the .Net Framework
installed.

Exposing a Remoting server that enables remote clients to register sponsors
Threat: There is no limit on the number of sponsors that can be registered.

See
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconautomaticdeserializationinnetremoting.asp for more info.

So I think strongname is not the cause of the problem. It should caused by
what you are marshalling via remoting.

From above, we know the Full level need to be enabled when we want to pass
following objects.
Full Level Security:
? ObjRef objects passed as parameters.
? Objects that implement the ISponsor interface.
? Objects that are inserted between the proxy and client pipeline by the
IContributeEnvoySink interface.

I think the Full Level will not cause much performance hit, but as the
secenario listed above, the Remoting mechanism needs to do more job which
may have a little side effect.

Since you will authenticate the remoting call, so I think the Full level
will not cause the security concern in your scenario.

Best regards,

Peter Huang
Microsoft Online Partner Support