Programming WCF Services, 2nd Edition

Partially Trusted Hosts

The approach presented thus far for partially trusted services was predicated on having the code that uses AppDomainHost be running under full trust. This is because ServiceHost and the bindings will demand full trust in any hosting scenario not listed in Table D-1.

But what if the code launching the host is only partially trusted? You could use a similar solution to that employed by the clients, placing AppDomainHost and ServiceHostActivator in a fully trusted assembly, allowing partially trusted callers, and having them both assert full trust:

[PermissionSet(SecurityAction.Assert,Unrestricted = true)]
public class AppDomainHost : IDisposable
{...}

[PermissionSet(SecurityAction.Assert,Unrestricted = true)]
class ServiceHostActivator : MarshalByRefObject
{...}

While this approach works, it suffers from the same problems listed previously when the client blindly granted full trust to the proxy: it circumvents code-access security and disables a crucial security mechanism, introducing two security problems. First, it is incorrect to assume that the code opening the host has permissions to accept calls on the transport channels and to participate in WCF activities such as distributed transactions. Second, by asserting full trust and suppressing the stack walk, you leave open the possibility for the partially trusted code that launched the host to create a service with higher privileges to do its dirty deeds for it. For example, the hosting code may not have file ...