Puzzling CAS Issue

I have an application that uses remoting.
I have strongly named every assembly in the application.
I have granted FullTrust based on the key used for strongly naming.
(I did this by creating a code group with the membership criteria being the public key that the assemblies are signed with.)
I have done this on both the remote and local systems.

This application can be run from a local disk (no problem), a remote disk (network share - big problem) and from a web page where
it runs under IEEXEC (big problem)

The local application is designed to connect to multiple and arbitrary servers. I can connect to any server if I run from my
local drive. I can not connect to any server if I invoke through IEEXEC. (Even if the IIS is on my system.)

The problem that I want to solve is the IEEXEC invocation. If you look at the stack trace below find the line with the <<<<<<<<
on it. This method returns a CAO. I believe, based on other information, that the error is occurring on the actual return of the
CAO.

My understanding of CAS keeps telling me that I have not setup the code groups etc correctly, but I THINK that I have.

Any insight would be helpful and appreciated.

Exception:
An error occurred while processing the request on the server: System.Security.SecurityException: Request for the permission of
type System.Security.Permissions.SecurityPermission, mscorlib, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 failed.
at System.Security.PermissionListSet.CheckDemand(CodeAccessPermission demand, PermissionToken permToken)
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken permToken, CodeAccessPermission demand, StackCrawlMark&
stackMark, Int32 checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark, PermissionType permType)
at System.Security.CodeAccessPermission.DemandInternal(PermissionType permissionType)
at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter
serWriter, Boolean fCheck)
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[]
headers, Boolean fCheck)
at System.Runtime.Remoting.Channels.CoreChannel.SerializeBinaryMessage(IMessage msg, Boolean includeVersions)
at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage
requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders,
Stream& responseStream)
at System.Runtime.Remoting.Channels.Tcp.TcpServerTransportSink.ServiceRequest(Object state)
at System.Runtime.Remoting.Channels.SocketHandler.ProcessRequestNow()

Server stack trace:
at System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadToEndOfHeaders(BaseTransportHeaders headers)
at System.Runtime.Remoting.Channels.Tcp.TcpClientSocketHandler.ReadHeaders()
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders,
Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at KMS.Core.Remoting.Shared.SponsoredCAOSponsor.Register(ILease lease, SponsoredCAOBase cao)
at KMS.Core.Remoting.Shared.RemotingManagerBase.FinishCreateServerCAO(Type cao_type, SponsoredCAOSponsor cao_sponsor, Object[]
args_to_pass)
at KMS.Core.Remoting.Shared.RemotingManagerBase.CreateServerCAO(String cao_type_name, SponsoredCAOSponsor cao_sponsor,
LeaseTime cao_lease_time, Object[] args)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(MethodBase mb, Object[] args, Object server, Int32
methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean
fExecuteInContext)

Exception rethrown at [1]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at KMS.Core.Remoting.Shared.RemotingManagerBase.CreateServerCAO(String cao_type_name, SponsoredCAOSponsor cao_sponsor,
LeaseTime cao_lease_time, Object[] args) <<<<<<<<<<<<<<<<<
at KMS.HGS.Admin.MonitorPanel.ConnectToServer(String server_name, Int32 remote_port) <<< client call to remote server
at KMS.HGS.Admin.AdminMonitorMain.mnu_File_Connect_Click(Object sender, EventArgs e)

[5244 byte] By [RoyChastain] at [2007-12-17]
# 1

It sounds like you did setup your security policy correctly (you can always verify this by running caspol -rsg <assembly> to see what code groups your assembly matches or caspol -rsp <assembly> to see what permissions it will be granted).

What you're running into is the AppDomain boundary that IE is setting up -- that AppDomain is not FullTrust because IE doesn't know what your assembly's strong name is until it gets loaded into the domain.

You can find out more about this issue here: How to Provide Extra Trust for an Internet Explorer Hosted Assembly.

-Shawn

ShawnFarkas-MS at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 2
Thanks for the response. That even makes sense. Big Smile
Could you please elaborate a little on the

"...other is to Assert() all the permissions that your assembly needs at its entry points."

I am currious about the 'entry points' etc. The .exe involved requires about 20 DLLs to get anyting done. Do they all need asserts and if so where?

Thanks

RoyChastain at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 3

The Assert needs to come at the boundary between Internet Explorer and your assembly -- so anywhere that the next stack frame up is going to be IE you'll need to Assert to prevent the stack walk from hitting the AppDomain that IE set up for you.

-Shawn

ShawnFarkas-MS at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 4
Okay, that says to me that only the entry point to the .exe needs the assert. Is that correct or have I totally missed something?
RoyChastain at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 5

Right, unless you call other functions directly via JavaScript in an HTML page for instance. If you start with the Assert in Main(), and still see security issues, then just go to the base of the callstack, and you've found another entry point that needs to Assert as well :-)

-Shawn

ShawnFarkas-MS at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...
# 6
I put this line of code into main()
(new SocketPermission(System.Security.Permissions.PermissionState.Unrestricted)).Assert();
It did not solve the problem. Any suggestions?

Thanks

RoyChastain at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Base Class Library...

.NET Development

Site Classified