If you can consider your server to be safe from direct meddling, you don't
need to worry about a client directly disabling CAS on your server.
However, that still wouldn't necessarily make SNIP
(StrongNameIdentityPermission) a good choice here. For starters, I have
serious doubts regarding whether a SNIP demand would cross a remoting
boundary. However, even if it could, it still wouldn't be trustworthy since
disabling CAS is not the only trivial way to cheat a SNIP check. For
example, in your remoting scenario, a malicious caller could delay sign his
own spoofing assembly with your public key then enable verification skipping
for the assembly on his own client machine.
In a way, the above is really just one example of the more general problem:
servers cannot trust clients. No matter what kind of mechanism you try to
put into place to help a server validate the client code's identity, an
attacker will be able to find a workaround since the server essentially
treats the client as a black box. If malicious code can adequately mimic
responses coming out of that black box, your server will not be able to
distinguish between it and a legitimate client.
The main implications of this are:
1. Servers should never trust that any client-provided data has been
validated on the client. All data should be re-validated, even if the
expected client will have pre-screened the data it submits to the server.
2. Servers should never use the self-declared identity of calling code as a
criterion when determining server-side permissions. The user's identity
should be used instead, and this identity should be communicated to the
server in a manner that minimizes the chances of spoofing by the caller.
(e.g.: Windows integrated authentication would be a lot safer than passing
the user name as a parameter to a server-side method.)
In addition to the above protections, you may wish to implement a licensing
scheme, but its main purpose should be preventing unlicensed client
machines, not unlicensed assemblies, from calling your server. Basically,
once a license (or any other "caller ticket") is available on a client
machine, it will become possible for a malicious user to use that license to
call your server.
BTW, on the side issue of authoring a custom permission, it's not generally
worthwhile either. The main reason for implementing this sort of check as a
permission in the first place is usually to enable the user of declarative
security statements (i.e.: permission attributes) in order to add
corresponding demands to one's code. However, permission attributes are
only used by the .NET Framework if their containing assembly has been
designated as a policy assembly in the running machine's security policy
configuration. Therefore, in order to bypass declarative demands for a
custom permission, a malicious user merely needs to remove the assembly
declaring the permission attribute from the local policy assemblies list.
Once this is done, your code will run as if the declarative demands were not
present at all.
