This is
an interesting article about code security in the CLR, and how little teeth the declarative
security features in the CLR have when it’s running fully trusted code. I did know
that some naughty things (like calling private methods) was possible using reflection,
but I was under the assumption that IStackWalk.Deny() trumphed
most anything. In the article, Keith shows how to malicious code can get around that
and also AppDomain separation — if the assembly it’s in is marked as FullTrust.
Fully trusted code can get around all of the CLR’s built-in security
features. That’s why it’s called fully trusted – it must be trusted to do the
right thing.
