StrongNameIdentityPermission LinkDemand versus internal

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I was wondering what the difference is between decorating a class (or method)
with StrongNameIdentityPermission LinkDemand and declaring a class internal?
Is one more secure than the other? Would there be a reason to use both?

Thank you for your comments?

Kevin
 
Internal methods can only be called by code declared within the same assembly. The StrongNameIndentityPermission allows code outside the assembly to call the method but only if it's assembly has the appropriate strong name.

Internal methods can be called by any code running with fulltrust if it uses reflection, but code guarded by the StrongNameIndentityPermission is alos guarded against reflection based invocation.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

I was wondering what the difference is between decorating a class (or method)
with StrongNameIdentityPermission LinkDemand and declaring a class internal?
Is one more secure than the other? Would there be a reason to use both?

Thank you for your comments?

Kevin
 
Richard Blewett said:
Internal methods can be called by any code running with fulltrust if it
uses reflection, but code guarded by the
StrongNameIndentityPermission is alos guarded against reflection based
Click to expand...
invocation.

Only if the caller is well-behaved, and one could argue that an attempt to
invoke internal or SNIP-protected members via reflection isn't particularly
"nice". If the attempt is indeed malicious, SNIP won't be much protection
at all since it's trivial to bypass by disabling CAS or skipping strong name
verification.
 
Well only if the malicious attempt is on a machine under the control of the attacker. If it happens to be happening on your machine that a malicious component that happens to be running with full trust is deployed then no - it will not be able to bypass StrongNameIdentityPermission - unless the user running the malicious software is an admin in which case you have bigger problems

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

Richard Blewett said:
Internal methods can be called by any code running with fulltrust if it
uses reflection, but code guarded by the
StrongNameIndentityPermission is alos guarded against reflection based
Click to expand...
invocation.

Only if the caller is well-behaved, and one could argue that an attempt to
invoke internal or SNIP-protected members via reflection isn't particularly
"nice". If the attempt is indeed malicious, SNIP won't be much protection
at all since it's trivial to bypass by disabling CAS or skipping strong name
verification.
 
Sorry, but the calling code does not need to be run in an admin user context
to bypass SNIP checks. In addition, there are plenty of scenarios in which
a machine administrator may be considered potentially malicious wrt any
given piece of code. For example, an ISV may consider its clients to be
potential abusers of libraries that the clients have not paid to use outside
the applications with which they are packaged. Similar scenarios can also
be encountered within a single enterprise where, for example, a satellite
location might attempt to misuse a centrally distributed application. The
"attackers" in such cases rarely considers that their actions are malicious,
but the software provider may have a very different opinion.
 
So in the end SNIP is just annoying the attacker not really providing any
protection. Right?
 
Sorry, yes, the code needs also to be running with partial trust, otherwise it can simply disable CAS itself using the SecurityManager

SecurityManager.SecurityEnabled = false;

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

Sorry, but the calling code does not need to be run in an admin user context
to bypass SNIP checks. In addition, there are plenty of scenarios in which
a machine administrator may be considered potentially malicious wrt any
given piece of code. For example, an ISV may consider its clients to be
potential abusers of libraries that the clients have not paid to use outside
the applications with which they are packaged. Similar scenarios can also
be encountered within a single enterprise where, for example, a satellite
location might attempt to misuse a centrally distributed application. The
"attackers" in such cases rarely considers that their actions are malicious,
but the software provider may have a very different opinion.
 
Neither limited accessibility (e.g.: internal modifier) nor SNIP provide any
serious deterrent to a determined and/or priviledged attacker. That said,
they do have other benefits, and not all code needs to be protected against
all possible threats, so you'll need to make some decisions about what's
worth implementing.

Low accessibility helps you constrain even your own use of your code. This
has multiple benefits, such as reducing your testing requirements, so you'll
probably want to restrict visibility as much as possible/reasonable
irrespective of whether it provides true security benefits. However, it
remains important to recognize that you can't count on low accessibilty to
enforce security.

SNIP is essentially just a mechanism for declaring access by only "friends
and family" assemblies, essentially attempting to enforce an accessibility
level that isn't available in current production versions of the .NET
Framework. It is not a reasonable substitute for a robust licensing scheme
since it is too easily bypassed.

If you're concerned about potential breach of your accessibility and/or SNIP
protections, you essentially have only a few options:

1. Obfuscate your assemblies, thereby making it more difficult to determine
what any given piece actually does. If you're lucky, this may push the
effort required to use your code past the level required to try to reproduce
the same functionality from scratch, thereby making your code an
unattractive target for at least some types of attacks.

2. Make attempted breach of the protections an offense under any relevant
license (for ISV) or employment contract (for internal applications). Since
you're unlikely to discover any breaches, this isn't a great protection, but
at least attackers can't say they weren't forewarned, and it might be enough
to discourage at least a few. Also, you should keep in mind that a
developer may not realize that they are circumventing SNIP if CAS has
already been disabled on their machine. (Coding against low accessibility
members is always a conscious decision since it requires use of reflection.)

3. If you can move "sensitive" code onto a machine that is at less risk, do
so.

4. Use a licensing scheme instead of SNIP and in addition to low
accessibility in order to restrict callers to your code. This is a lot of
work, can affect performance, and won't help restrict access to private
member variables via reflection in all scenarios. Its only real benefit is
that it will likely be harder to circumvent than SNIP.

5. Check that CAS is enabled and callers are fully strongly signed (as
opposed to delay signed). Same cons as licensing. Just makes it more
difficult to bypass SNIP protections.


1-3 are almost always worth implementing. I wouldn't recommend 4 or 5
except for truly sensitive methods and, even then, the implementation
details should probably be bundled into a single "is it OK to run?" method
that can be easily changed.
 
Have you actually tried it? In order to disable CAS for the current
process, exactly two CAS permissions are required (both of which will be
granted to all locally installed code under default policy settings), but
the user does not need the elevated permissions that would be required to
persist the change for use in other processes. Under default ACLs, a member
of the local Users group should have no problem running the required code.
 
Back
Top