Keith Brown has made available for free, in the format of an online wiki, the contents of his book...

Links:

http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HomePage.html

Continuing briefly from

Where the heck is the graphical .NET Framework Configuration Tool (Mscorcfg.msc)

One opinion as to why it was removed

> The GUI based tool is just as complicated to use as caspol for an non
> educated user, to the contrary, it gives you the illusion that it's easier
> to use than caspol, that's exactly why it was removed from v2.0 and now
> it's only included with the SDK.
> Caspol.exe is the tool that comes with the runtime, that is why it's
> called an end-user tool, and it's meant to be used by an "administrator" .
> I agree that you can use System.Security from your setup code, but you can
> do exactly the same using caspol.exe without you writing any code, and
> what if the security configuration changes lets say due to infrastructure
> changes? You ain't gonna write a program, while a simple batch file that
> uses caspol can do the same without you writing any code.

Links:

Where the heck is the graphical .NET Framework Configuration Tool (Mscorcfg.msc)

http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework/2005-11/msg00162.html

The following code, which I found at MSDN, could be interesting foundation for a Shell Extension or a Visual Studio custom Tool...

using System;
using System.Collections;
using System.Diagnostics;
using System.Security;
using System.Security.Permissions;
using System.Security.Policy;
using System.Reflection;
using System.IO;

namespace SimpleSandboxing {
 class Program {
  static void Main(string[] args) {
   // Create the permission set to grant to other assemblies.
   // In this case we are granting the permissions 
   // found in the LocalIntranet zone.
   PermissionSet pset = GetNamedPermissionSet("LocalIntranet");
   if (pset == null)
    return;
   // Optionally you can create your own permission 
   // set by explicitly adding permissions.
   //  PermissionSet pset = 
   //   new PermissionSet(PermissionState.None);
   //  pset.AddPermission(new SecurityPermission(
   //   SecurityPermissionFlag.Execution));
   //  pset.AddPermission(
   //   new UIPermission(PermissionState.Unrestricted));
   AppDomainSetup ads = new AppDomainSetup();
   // Identify the folder to use for the sandbox.
   ads.ApplicationBase = "C:\\Sandbox";
   // Copy the application to be executed to the sandbox.
   File.Copy("HelloWorld.exe", "C:\\sandbox\\HelloWorld.exe", true);

   Evidence hostEvidence = new Evidence();
   // Commenting out the following two statements 
   // has no effect on the sample.
   // The grant set is determined by the grantSet 
   // parameter, not the evidence for the assembly. 
   // However, the evidence can be used for other reasons, 
   // for example, isolated storage.
   hostEvidence.AddHost(new Zone(SecurityZone.Intranet));
   hostEvidence.AddHost(new Url("C:\\Sandbox"));

   // Create the sandboxed domain.
   AppDomain sandbox = AppDomain.CreateDomain(
    "Sandboxed Domain",
    hostEvidence,
    ads,
    pset,
    GetStrongName(Assembly.GetExecutingAssembly()));
   sandbox.ExecuteAssemblyByName("HelloWorld");
  }

  /// <summary>
  /// Get a strong name that matches the specified assembly.
  /// </summary>
  /// <exception cref="ArgumentNullException">
  /// if <paramref name="assembly"/> is null
  /// </exception>
  /// <exception cref="InvalidOperationException">
  /// if <paramref name="assembly"/> does not 
  /// represent a strongly named assembly
  /// </exception>
  /// <param name="assembly">Assembly to create a StrongName for</param>
  /// <returns>A StrongName for the given assembly</returns>
  /// 
  public static StrongName GetStrongName(Assembly assembly)
  {
   if (assembly == null)
    throw new ArgumentNullException("assembly");

   AssemblyName assemblyName = assembly.GetName();
   Debug.Assert(assemblyName != null, "Could not get assembly name");

   // Get the public key blob.
   byte[] publicKey = assemblyName.GetPublicKey();
   if (publicKey == null || publicKey.Length == 0)
    throw new InvalidOperationException("Assembly is not strongly named");

   StrongNamePublicKeyBlob keyBlob = new StrongNamePublicKeyBlob(publicKey);

   // Return the strong name.
   return new StrongName(keyBlob, assemblyName.Name, assemblyName.Version);
  }
  private static PermissionSet GetNamedPermissionSet(string name)
  {
   IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy();

   // Move through the policy levels to the machine policy level.
   while (policyEnumerator.MoveNext())
   {
    PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current;

    if (currentLevel.Label == "Machine")
    {
     NamedPermissionSet copy = currentLevel.GetNamedPermissionSet(name);
     return (PermissionSet)copy;
    }
   }
   return null;
  }

 }
}

Links:

• MSDN: How to- Run Partially Trusted Code in a Sandbox

I wish I could write this clearly:

http://www.15seconds.com/issue/040121.htm

Although the command line caspol can do everything, I, like most users - prefer the mmc snapin (mscorcfg.msc) much better for small quick interventions.
It used to be installed by default with every framework, but as I'm sure you've noticed, since 2.0, it is only installed if you install the SDK...
I've always thought that as weird, but didn't have time to look into it.

Today I came across the official blurb of their policy:

The .NET Framework Configuration tool (Mscorcfg.msc) is a Microsoft Management Console (MMC) snap-in that enables you to manage and configure assemblies in the global assembly cache, adjust code access security policy, and adjust remoting services.

In the .NET Framework versions 1.0 and 1.1, Mscorcfg.msc is installed with the NET Framework redistributable package. In the .NET Framework 2.0 and later versions, Mscorcfg.msc is installed with the .NET Framework 2.0 Software Development Kit (SDK).

If you have both the .NET Framework 1.1 and 2.0 runtimes, you will have version 1.1 of the configuration tool, but you might not have version 2.0. If you want to manage .NET Framework 2.0 and later versions by using the configuration tool, you must install the .NET Framework 2.0 SDK. To change configuration settings for a computer that has multiple versions of the .NET Framework, you must make the changes in the matching versions of the configuration tool.

Note:

The .NET Framework versions 3.0 and 3.5 are built incrementally on the .NET Framework version 2.0. The configuration tool included in the .NET Framework 2.0 SDK is the latest version of the tool. You can use this version to manage code access security policy for the .NET Framework 3.0, 3.5, and later versions as well.

As usual...doesn't tell me much as to the reasoning of why it was removed...but at least, its "official", and I haven't missed an easier way of installing just the tool and leave the SDK download to others.

Which means I'm off to re-download 354Mb of stuff... just to get my hands on a tiny little tool...

Except...SDK 3.5 now supercedes SDK 2.0

But when you get to the SDK 2.0...you get the following blurb...

NOTE: This version of the .NET Framework SDK SDK has been superceded by the Windows SDK for Windows Server 2008 and .NET Framework 3.5. This version of the Windows SDK is available as either a

• Web Install or
• DVD ISO image

Which means I'm off to download the 3.5 SDK...with a size of....1330.0 MB !!!
Don't you just love these wild goose chases?

The Stupid Dog

Only problem...an hour later....is that after downloading and repairing what I've got on the computer...Not there! I even pulled out The Stupid Dog to see if it could find it:

Score so far? I've downloaded 1330 Mb to get just 41Kb ...WOW!

SDK 2.0 ...

So I have to now go back to Microsoft..this time to download the SDK 2.0 since those are the last known un-ambiguous instructions as how to get the Mscorcfg.msc

While Waiting for the Download to come in...Back to the Stupid Dog

Hum...look at that ...one of the files that Stupid Dog brought back is a .NET assembly...

Not in the location I expected...but maybe it would work?
Nothing to lose while waiting, by clicking, right?
What I get is;

Hum. Maybe I need to register the DLL with the same name? Maybe -- but is it a COM or NET assembly? Should be a .NET one...
Turns out it is:

So if my theory is right...just REGASM the mscorcfg.dll and it should work...

But no....Get an error saying its looking for a different version.
Almost though...
What's happening is the Stupid Dog brought back a very old version -- a Mscorcfg that is for 1.0. I would have seen that earlier if I had scrolled right and looked at the LastModifiedDate of the files... but I'm so friggin ticked off at this whole waste of time that I'm fuming in general:

So it's not registering on this machine.  Close...I'm sure I'm on the right track...but no cigar yet.

It seems that there's nothing else that I can do except wait for the download of version 2.0 SDK. Rats.

Waiting...

Waiting....

Waiting...

GROWL!!!

This ...is ridiculous.
Can't believe it....1.5 Gb of download to find a 41kb tool.
Shame on you MS, either for the instructions, or packaging...or both.

Finally...Stupid Dog brings back:

Which means I can try my theory:

First unregister it...

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regasm /unregister "C:\Program Fil
es\Microsoft.NET\SDK\v2.0\Bin\mscorcfg.dll"
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004.  All rights reserved.

Types un-registered successfully

And I get right back to the error I had before...

Regasm it again:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>regasm "C:\Program Files\Microsoft
.NET\SDK\v2.0\Bin\mscorcfg.dll"
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004.  All rights reserved.

Types registered successfully

And it works!

So...moral of the story...it appears that next time don't download the SDK's -- you just need a zip containing the two files:

Wow. What a WASTE of time that hell was.

Links:

• Blurb: http://msdn.microsoft.com/en-us/library/2bc0cxhc.aspx
• SDK 2.0: .NET Framework 2.0 Software Development Kit (SDK) (x86) (354Mb...rats!) 
• Windows SDK for Windows Server 2008 and .NET Framework 3.5

This thread, at the oh-too-common problems it talks about (namely that invariably not all stations will have the same security settings, and things will stuff-up on some stations), is well answered by this post by Peter Bromberg is worth holding onto:

if this is for users in the enterprise to run locally on their own machines, then the following snippet from Shawn Burke of MS should be helpful:

1. Sign your application with a strong name
2. Open up the mscorcfg.msc applet (Control Panel >> Admin Tools >>
   Microsoft .NET Framework Configuration)
3. Select Runtime Security Policy -> Enterprise, Actions >> New to create a
   new code group based on a StrongName
4. Navigate to your assembly or put in your public key
5. Select the permission set you would like
6. Go to Actions >> Create Deployment Package for the Enterprise level

This will create an msi that you can roll out to your organization.
It will tell all of the machines in your organization to treat
assemblies with the given StrongName in the code group you created that they
can do the operation.  The nice thing about this is that you're
specifically trusting this code, not all code.

Link:

• http://www.eggheadcafe.com/community/aspnet/2/11173/if-this-is-being-deployed.aspx

Parking a link: http://weblogs.asp.net/hernandl/archive/2005/11/21/permcalcftissues.aspx

  This is a keeper for hints as to how to limit FullTrust access by partimentalizing, etc.:

 http://blogs.msdn.com/shawnfa/archive/2005/12/14/502826.aspx

Note:

I agree that it doesn't come up too often, but It has -- sometimes in the weirdest places....: eg 3rd party code that gets to the application name like this:

Process process = Process.GetCurrentProcess();
string s = process.ProcessName;

These kind of things really get the mustard up my nose!

I'm looking into locking down a method that iterates on the EventLog (which in itself is a high-risk operation but that's a different issue).

Know what i just bumped into???

I'm starting to agree with this recommendation (wish I had known about it a long time ago):

<<<

It is an annoying process to add security after the fact, the best
recommendation I've seen is to develop as a least permission user (VS
Debugger user etc) or to remove all default permissions with [assembly:
PermissionSet(SecurityAction.RequestOptional, Unrestricted=false)] up
front.
As you add functionality and it throws security exceptions run you can
research what permissions each object needs.

>>>

Src: http://www.secnewsgroups.net/group/microsoft.public.dotnet.security/topic11068.aspx