Hi Holger. In this particular example, yes, I must have UnmanagedCode to
even call my method. I would have expected that the compiler generate code
that doesn't needlessly leak demands. If I must have UnmanagedCode to use
"catch(std::exception)" the implementation detail of using
GetExceptionPointers (and its LinkDemand for UnmanagedCode) should be hidden.
Reliably hiding this in generated code would be awfully difficult while
directly calling GetExceptionPointers because there's no guarantee this
assembly won't be partially trusted. The only way to reliably hide this
would be to push the call to GetExceptionPointers into a system assembly
(which would then do a Demand/Assert pair so it no longer leaks the
LinkDemand) since system assemblies are guaranteed to have FullTrust.
Yes, *I* can simply add an Demand/Assert pair to get rid of the FxCop
warning. But, I know that's a correct way of getting rid of the message for
partially trusted callers. But, this then means my assembly must not be
denied Assert and usually means this assembly must been installed with
elevated permissions compared to its callers.
The FxCop documentation for CA2122 suggests mirroring the LinkDemand on the
method that calls GetExceptionPointers which pushes an new LinkDemand one
level up the stack, which could have huge ramifications if the next caller up
the stack is a method not in this assembly and does not need UnmanagedCode
and is either refusing it or ClickOnce security has filtered it out in it's
manifest previously.
It would appear the best course of action would normally be to ignore this
warning; but, that's not what normally happens when encountering an FxCop
warning. Users usually either do what the warning suggest (which, in this
case, would effectively make a LinkDemand into a Demand by continuously
cascading the LinkDemand up the graph--adding the LinkDemand to this method
would mean the warning shifts to methods that call this method, ad nauseam)
or they fiddle around with attributes/code until the warning goes away.
Doing this usually defeats the purpose of the original warning and often
makes the application more susceptible to attack, not less.
--
Browse
http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#
"Holger Grund" wrote:
"Peter Ritchie [C# MVP]" <PR****@newsgroups.nospamwrote
I've purposely been ignoring a CA2122 warning in some C++ interop code
I've
been working on for quite some time. I've just recently had the cycles to
investigate the warning. The warning message is as follows
Warning CA2122 : Microsoft.Security : MyClass.Method():Void calls into
Marshal.GetExceptionPointers():IntPtr which has a LinkDemand. By making
this
call, Marshal.GetExceptionPointers():IntPtr is indirectly exposed to user
code. Review the following call stack that might expose a way to
circumvent
security protection:
->System.Runtime.InteropServices.Marshal.GetExcepti onPointers : IntPtr
->MyClass.Method : Void
...
I must admit the diagnostic message is a bit odd. I think it is trying to
tell you that you should make sure that you do not expose the effects
or results of calling GetExceptionPointers to untrusted callers in the
chain.
void MyClass::Method()
{
try
{
return MethodImplementation();
}
catch(std::runtime_error &)
{
//...
}
}
My concern isn't that FxCop/Code-Analysis is pumping out this message,
it's
the LinkDemand that catch(std::runtime_error) is forcing upon this method.
What's the problem? You'll need unmanaged code, anyway.
GetExceptionPointers is not directly exposed -- even though you'd
effectively
have to trap all exceptions (including C++ and async exceptions), which is
hardly a good idea.
Assume for a moment that the method MethodImplementation is not within my
control (cannot modify it) and it can obviously throw an
std::runtime_error
reference. While I can add a LinkDemand attribute to the Method method,
Adding the LinkDemand would just shut up FxCop. What's the problem
if MethodImplementation throws a std::runtime_error? I don't see how
a caller of Method could possibly do anything to exploit that.
Any thoughts?
How about just ignoring the message? I don't see any problem.
-hg