When I run fxcop against my vb app (MyApp, FW 1.1, a vb winforms program), I
get some complaints about LinkDemands, namely:
    "Do not indirectly expose methods with link demands"
What am I supposed to do about this?  I have read a lot of material about
this and
I have no clue as to what I am supposed to do, if anything.

I tried putting
  <Permission(Permissions.SecurityAction.LinkDemand, UnmanagedCode:=True)> _
in front of the offending call, and after some trial and error, I can get an
error to go away, but fxcop then complains about some new ones.  After a
little more of this, I concluded that I was chasing my tail.

Some examples are shown below.  First comes what I am trying to do, 2nd
comes where fxcop complained, and 3rd comes my code that called the offender.

my vb main adds an unhandled exception handler via AddHandler. ->System.AppDomain.add_UnhandledException(System.UnhandledExceptionEventHandler) : Void
->MyApp.MyAppModule.Main : Void

My vb LastErrorText calls GetLastWin32Error for error reporting
->System.Runtime.InteropServices.Marshal.GetLastWin32Error : Int32
->MyApp.Unclean.LastErrorText(System.Int32) : String

My TrimWorkingSet calls GetCurrentProcess leading to ultimately leading to
SetProcessWorkingSetSize
->System.Diagnostics.Process.GetCurrentProcess : Process
->MyApp.Unclean.TrimWorkingSet : String

My DiagnosticDump calls get_StartInfo by referencing StartInfo of a process
it launched
->System.Diagnostics.Process.get_StartInfo : ProcessStartInfo
->MyApp.Unclean.DiagnosticDump(System.Exception) : String

My MyAppFindFile calls CurDir
->Microsoft.VisualBasic.FileSystem.CurDir : String
->MyApp.MyAppGlobal.MyAppFindFile(System.String) : String

My MyAppGlobal constructor calls FileDateTime to get the create time of
MyApp.exe
->Microsoft.VisualBasic.FileSystem.FileDateTime(System.String) : DateTime
->MyApp.MyAppGlobal.#ctor : Void

In general, one would want to protect any members that expose those target
methods with link demands or full demands for the same permissions specified
in the original link demand.  This will ensure that your code can't satisfy
a link demand on behalf of a less privileged caller without forcing the
caller to pass a demand for the same permission.


If you're not sure what permission is being evaluated in the original link
demand, you may want to use a decompilation tool like Reflector
(http://www.aisto.com/roeder/dotnet/) to examine it.  This is a lot less
work than trial and error... ;)


Sorry, but I can't seem to make heads or tails of that list (which probably
has more to do with painkillers I'm taking for a broken leg than anything
inherent to your list <g>).  If the matching link or full demand approach
doesn't work, perhaps you provide a simple and complete code sample that
provokes FxCop into the complaint that you're trying to address?  If it's
compileable, I'd be quite willing to help run through the resolution...

Thanks for your response.

Indeed.  I have read that (at least it sounds familiar).  But I am as
clueless as ever.  My objective is to make fxcop stop complaining about link
demands.  I can do that by turning off this fxcop rule, but that seems like
cheating.  Or, I can do X.  What is X?  I am clueless.

Sorry, I probably should have been clear and complete about 1 or 2 rather
than brief about 6 (some of the list is copy/pasted from fxcop's complaints).
What I meant to indicate by:

my vb main adds an unhandled exception handler via AddHandler. ->System.AppDomain.add_UnhandledException(System.UnhandledExceptionEventHandler) : Void
->MyApp.MyAppModule.Main : Void

is this:

In my vb main, I use AddHandler to enable an exception handler for the
UnhandledException exception.  Fxcop complains about add_UnhandledException
(called from Main) as a LinkDemand security hole.


Yes - the full demand approach.  I've heard of that too.  What is it?  What
do I do?  My middle name is clueless.

Below is a vb module that compiles clean for me.  Paste it into a vb test
program of your own, or create a new vb app and paste it there.  Subs T0, T1,
T2, and T3 each contain a single line that causes fxcop to complain re link
demands.  Comment one of the lines out and one of fxcop's complaints goes
away.

Public Module ExhibitLinkDemands
  ' lines commented with FXCOP cause the following fxcop warning:
  '   Do not indirectly expose methods with link demands
  ' comment out the line and the warning goes away
  Private Sub MyHandler(ByVal sender As Object, ByVal args As
UnhandledExceptionEventArgs)
  End Sub
  Public Sub T0()
    AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf
MyHandler ' FXCOP
  End Sub
  Public Sub T1()
    Dim s As String = CurDir() ' FXCOP
  End Sub
  Public Sub T2()
    Dim s As String = Microsoft.VisualBasic.FileSystem.FileDateTime("") '
FXCOP
  End Sub
  Public Sub T3()
    Dim p As Process = System.Diagnostics.Process.GetCurrentProcess() ' FXCOP
  End Sub
End Module

FYI, I am using VS 2003, FW 1.1, latest SPs.

X is the application of a link demand attribute to your own method to match
the link demand that has been placed on the method that you are calling from
your code.  Let's say you have written a method Foo that calls into a method
Bar, and Bar is protected by a link demand for
SecurityPermission\UnmanagedCode.  In order to avoid the problem that FxCop
is warning you about, you should add a link demand or full demand for
SecurityPermission\UnmanagedCode to your Foo method.  (More on the details
of how to do this at the example later in this message...)

Show quoteHide quoteOK, let's start with that line.  The setter for the
AppDomain.UnhandledException event handler is protected by a link demand for
SecurityPermission\ControlAppDomain.  Unfortunately, the MSDN documentation
for the event doesn't provide this level of detail regarding the security
requirements, but you can see the permission attribute if you look at the
event code in Reflector, where the code for the setter will look like this:

<MethodImpl(MethodImplOptions.Synchronized),
SecurityPermission(SecurityAction.LinkDemand, ControlAppDomain:=True)> _
Public Sub add_UnhandledException(ByVal value As
UnhandledExceptionEventHandler)
      '...
End Sub

The "SecurityPermission(SecurityAction.LinkDemand, ControlAppDomain:=True)"
bit in the attributes is the link demand for
SecurityPermission\ControlAppDomain.  In order to prevent the problem that
FxCop is complaining about, you can simply add the same link demand to your
T0 method.  e.g.:

<SecurityPermission(SecurityAction.LinkDemand, ControlAppDomain:=True)> _
Public Sub T0()
        AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf
MyHandler
End Sub


The CurDir function is actually a method of the
Microsoft.VisualBasic.FileSystem type.  The FileSystem type is protected by
a link demand for unrestricted SecurityPermission.  In Reflector, it looks
like this:

<StandardModule, SecurityPermission(SecurityAction.LinkDemand,
Unrestricted:=True)> _
Public NotInheritable Class FileSystem
    '...
End Class

To avoid the problem that FxCop is warning you about, add the same link
demand to your method that calls CurDir.  e.g.:

<SecurityPermission(SecurityAction.LinkDemand, Unrestricted:=True)> _
Public Sub T1()
        Dim s As String = CurDir()
End Sub


It's the same link demand on the Microsoft.VisualBasic.FileSystem type that
you need to deal with here, so add the same link demand as for the T1
method.

The System.Diagnostics.Process type has a link demand for unrestricted
permissions (aka "full trust"), so that's what you need to add to your T3
method.  e.g.:

<PermissionSet(SecurityAction.LinkDemand, Unrestricted:=True)> _
Public Sub T3()
        Dim p As Process = System.Diagnostics.Process.GetCurrentProcess()
End Sub


The code is almost exactly the same.  However, you would specify
SecurityAction.Demand instead of SecurityAction.LinkDemand in your
attribute.  e.g. (using your T0 method):

<SecurityPermission(SecurityAction.Demand, ControlAppDomain:=True)> _
Public Sub T0()
        AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf
MyHandler
End Sub

The main benefit of a full demand over a link demand is that callers to a
method protected by a full demand are much less likely to inadvertently
satisfy the demand on behalf of potentially malicious callers.  In other
words, if a method is protected by a full demand, the poor developer who
writes code against it doesn't need to run FxCop to discover that he ought
to be adding additional permission verifications to his own code. ;)

Thanks very much for your help on this.  It will take me some time to
understand all of it -  spin up on Reflector, figure out how to translate
what I see there into a demand or a link demand (this appears difficult to me
at the moment, but I'm just getting started), and apply this to other
security matters.  Fxcop complains to me about some other security items, but
I have enough on my plate for a while.

If you wouldn't mind, I have two less detailed questions in this area.

1.  Does this stuff get any easier in .net 2005, fw 2?  I'm 2003 fw 1.1, and
maybe I can save some brain cells if I defer link demands until I upgrade.

2.  Cleaning up link demands sounds more important for class/control
libraries than windows forms apps, or are their vulnerabilities about the
same?  Your response here may help me decide what to fix first.

<snip>
Nope, it's pretty much the same in 2005.



It's definitely a bigger worry for class libraries, particularly those that
are meant to be installed in the GAC or that will used by other developers.
(Most of the FxCop rules are targeted at such library assemblies, and there
are quite a few rules that you may wish to systematically ignore when
working on "end" applications.)  Depending on the deployment target(s) for
your Windows Forms apps, ignoring this link demand rule for your executables
might not be much of a risk.  However, you may want to keep in mind that
executables can be referenced and used as library assemblies, as well as
invoked via reflection, so adding the link demand protection might be a good
idea if your application will be deployed to environments where it might be
subjected to potentially malicious calls.  That said, there are very many
developers who don't run FxCop on their assemblies at all and are blissfully
unaware of their potential link demand problems, so you won't exactly be in
the minority if you don't add the link demands to your executables.

On a practical note, if you find dealing with the link demands to be
difficult, you might want to start by applying the FxCop recommendations
only to your class libraries.  With a bit of practice, you'll probably find
that it takes only a minute or so to track down and apply the appriate
permission demand attribute to your code, so why not ease yourself into it
and only ramp up to handling your EXEs until after you've acquired the
knack?

I was wrong about this in my previous message.  Version 2.0 of the Framework
does contain functionality that will help reduce the workload here.  By
marking your assembly as security-transparent, you can indicate that it
cannot fulfill link demands on behalf of calling code, which will avoid the
need to address the link demands one by one.  Marking an assembly as
security-transparent involves adding a single assembly-level attribute:

<Assembly: System.Security.SecurityTransparent()>

Thanks very much for your help.  I've made some progress and I'm getting an
education.  Since most link demands that remain are particular to different
exe's, I think I'll continue but more in a back burner mode pending upgrade
to 2.0.

System.Security.SecurityException was unhandled
How to encrypt/decrypt a file
Problem with RSA.ImportParameters() under ASP .NET
ReflectionPermission weird behavior?
after changed the permisssion set to "nothing", I can't set the .net configuration anymore?
moving .net containers
CryptoAPI
impersonation in vb.net
web.config security conn-str and auth-info
Blocking hyperlink access to 'secured' website