What are the security implications for accepting anonymous methods (Action<>, Func<>) as parameters?

Question

Just as the title says: What, if any, are the security implications that need to be considered when using and/or passing around anonymous methods (Action<>, Func<>) in C#?

A method which accepts Action<>/Func<> seems to be a potential way for foreign code to be injected into a program. For the record, I understand that the injected method or function is not able to do inherently unsafe things in the sense of arbitrary memory access, but I would think that it could allow the calling code to call e.g. arbitrary .Net framework functions, corrupt data, or otherwise cause the application to misbehave.

Is this assumption wrong?

If it is not, what should be done to lock these down? Additionally, is there any way to validate the /Func<> that is passed into a method or function to ensure that it is of an expected form or to restrict its access to certain types and namespaces?

Also, forgive me if I'm not quite using the right terminology, I'm still learning.

Answer 1

A method which accepts Action<>/Func<> seems to be a potential way for foreign code to be injected into a program

That is completely wrong. Whoever is calling your function and passing a delegate is, by definition, already running code in your program.
Any code which is passing a delegate can already do whatever it wants. You cannot have security boundaries within the same AppDomain. (older versions of .Net had Code Access Security, which tried to do this, but was not a good idea)

However, it can create unexpected reentrancies, which can cause issues with thread-safe code.

Answer 2

I'm really asking if there are scenarios

Back when CAS policy was still being used (e.g. medium trust ASP.NET) a trusted piece of code could not safely call untrusted code when stack asserts are present. For example when

new SecurityPermission(Unrestricted).Assert()

was in effect the security check stack walk would stop at this point. That can lead to untrusted code not being detected. See the docs for Assert.

I'm being a little vague here because the scenario is hard to pull off and it is obsolete.

---

In case there is no trust boundary inside of the same process the caller already has all the power even without injecting code somewhere. No need for that.