Although the v1.0 and v1.1 versions of CasPol provided a switch to disable the CLR's security system, running without CAS enforcement on was never a scenario that we encouraged for obvious reasons.  The choice to disable security was a system wide switch that affected any managed application on any version of the runtime, and made running managed code incredibly unsafe.

As of Whidbey, you'll find that the switch to turn security off no longer works as it used to.  If you run caspol -s off with beta 2 or later of Whidbey installed, you'll see:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215>CasPol.exe -s off
Microsoft (R) .NET Framework CasPol 2.0.50215.44
Copyright (C) Microsoft Corporation. All rights reserved.

CAS enforcement is being turned off temporarily. Press <ENTER> when you want to
restore the setting back on.

Security will then be disabled as long as the CasPol process remains active.  When CasPol is terminated, it returns security to the on state.  Even abruptly terminating the CasPol process will still return security to its on state. 

This works because the implementation of the internal security off flag has changed.  Instead of using a registry key to indicate the status of CLR security, we now use a named mutex which CasPol holds to indicate to the CLR that it should disable security.  Examining the the handles held by the CasPol process in a debugger will enable you to quickly identify this mutex:

0:000>!handle 0 4 Mutant
Handle 4c
  Name          \BaseNamedObjects\CLR_CASOFF_MUTEX
Handle 428
  Name          <none>
Handle 4a8
  Name          \BaseNamedObjects\ShimCacheMutex
Handle 624
  Name          <none>
4 handles of type Mutant

Since security is being disabled by this mutex, the CasPol process is resilient to being terminated unexpectedly, because Windows will just clean up the handle for CasPol when cleaning up the process.  Another side effect is that if the machine is rebooted, the security state will revert to on.

If we fire up the kernel debugger, we can take a look at the ACL of the mutex:

lkd> !object \BaseNamedObjects\CLR_CASOFF_MUTEX
Object: 85088d88  Type: (8679f040) Mutant
    ObjectHeader: 85088d70
    HandleCount: 1  PointerCount: 2
    Directory Object: e179f980  Name: CLR_CASOFF_MUTEX

lkd> dt nt!_OBJECT_HEADER 85088d70
   +0x000 PointerCount     : 2
   +0x004 HandleCount      : 1
   +0x004 NextToFree       : 0x00000001 
   +0x008 Type             : 0x8679f040 
   +0x00c NameInfoOffset   : 0x10 ''
   +0x00d HandleInfoOffset : 0 ''
   +0x00e QuotaInfoOffset  : 0 ''
   +0x00f Flags            : 0x20 ' '
   +0x010 ObjectCreateInfo : 0x853e3678 
   +0x010 QuotaBlockCharged : 0x853e3678 
   +0x014 SecurityDescriptor : 0xe2c57b2c 
   +0x018 Body             : _QUAD

lkd> ?? 0xe2c57b2c & ~0x7
unsigned int 0xe2c57b28

lkd> !sd e2c57b28 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
->Owner   : S-1-5-32-544 (Alias: BUILTIN\Administrators)
->Group   : S-1-5-21-2127521184-1604012920-1887927527-513 (Group: REDMOND\Domain Users)
->Dacl    : 
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x34
->Dacl    : ->AceCount   : 0x2
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x18
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrators)

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x14
->Dacl    : ->Ace[1]: ->Mask : 0x001f0001
->Dacl    : ->Ace[1]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL


That shows that the mutex is created with an ACL that prevents anyone who isn't an administrator from owning it.  And although Windows does not provide a way to prevent non-administrators from creating this mutex, internally the CLR will not respect the existence of the named mutex if it is abandoned or not owned by the BUILTIN\Administrators group.  This prevents a squatting attack where a malicious user could turn off security simply by creating this mutex himself.

One of the more interesting effects to note of disabling security with this mutex is that the v2.0 CLR will no longer respect the registry key used by older versions of the runtime, and those versions will not have their security disabled by the new CasPol switch.

Although there still is the ability to turn off security, the ability to turn it off permanently has been removed.  The new switch is useful mostly for debugging purposes, to establish if a problem you're diagnosing is related to the security system or not.  The recommendation is still to avoid using this mechanism if at all possible.