This issue (and its cousin: Why Do I Still Get an Exception Accessing the Registry with Full RegistryPermission?) come up fairly frequently on the newsgroups.  The reasoning is actually very simple.

The exception being thrown in these cases arises from the fact that the CAS model sits on top of the security model provided by the underlying operating system, and does not replace it.  So if you're running Win9x or one of the Windows NT operating systems with the FAT file system on your drive, you'll never run into the problem.  On the other hand, if you're dealing with NTFS or the Registry on NT platforms, you will have to interact with the NT security model.

So, if I'm running as a normal user on a Windows NT machine, even if my assembly is located on the local machine and gets a grant set of FullTrust, I might still get an exception if I try to open c:\boot.ini, since the ACL on that file does not allow access to anyone outside the System account, and the Power Users or Administrators groups.  Similarly, attempting to write a registry key under HKLM while my process is running in the context of a normal user, even with Unrestricted RegistryPermission, will result in an exception.

If you think about it, this makes a lot of sense.  If the CLR were to have some sort of hook that bypassed NT security, and were to say "this managed code was granted FullTrust, let it do anything it wants", there would be a gaping hole opened up.  Imagine for a minute this were the case.  Now, I can log into a NT machine as guest, write an assembly to my %TMP% folder, and run it.  Since the assembly came from my local machine, by default it will get FullTrust.  And if FullTrust meant that NT security were bypassed, all of the sudden I can make myself and administrator on the machine that I was only a guest on previously.  Clearly that's not a very good model.

One easy way to tell if you're running into an issue with CAS or with NT ACLs is to check the type of exception you get.  If there's a problem with CAS you'll see a SecurityException.  As of v1.1 of the CLR, failing to complete an operation due to NT security should throw an UnauthorizedAccessException with a message along the lines of 'Access to the path "c:\boot.ini" is denied.' instead.