Why is this Code Access Security example broken?

Question

I know that CAS is of limited value, but I want to learn about it anyway.

I don't understand the behavior I'm seeing: Basic default CAS seems not to work at all in my fairly normal environment.

Take this sample class:

using System;
using System.Security;
using System.Security.Permissions;

namespace CASNotWorkingExample
{
    class Program
    {
        static void Main(string[] args)
        {
            FileIOPermission perm = new FileIOPermission(PermissionState.Unrestricted);

            if (SecurityManager.IsGranted(perm))
                Console.WriteLine("granted");
            else
                Console.WriteLine("denied");

            Console.ReadKey();
        }
    }

}

I build this and put the exe, CASNotWorkingExample.exe, onto another machine (IP is 192.168.1.101) on a file share "untrusted". I then run it from a nonadministrative command prompt using \\192.168.1.101\untrusted\CASNotWorkingExample.exe, expecting it to return "denied". It does not; it returns "granted".

Windows knows it's dealing with a remote EXE of questionable security. When I run the same command from the start menu Run... dialog, I get the usual security warning "The publisher could not be verified. Are you sure etc. etc.". So it's not somehow mistakenly thinking the exe is running on the local machine and misassigning the zone.

Furthermore, when I look at the very same exe using the .NET 2.0 Configuration Tool (right-click "Runtime Security Policy", choose "Evaluate Assembly..."), I see that .NET is only assigning Internet_Zone permissions to the assembly. These permissions do NOT include FileIOPermission (Isolated Storage is its own permission).

alt text http://img5.imageshack.us/img5/2256/casperms.jpg

Data that might be useful to someone else but hasn't been to me so far:

• I ran into this while working through the MS Press book for the MCTS 70-536 exam. Chapter 11 is all about CAS; Lesson 1 / Example 1 fails for me, pretty much as described above. What you see here is a stripped-down variant of that.
• I have verified that an EXE such as this can actually write to disk, i.e. the IsGranted check is probably correct.
• The two machines are running Vista SP1 and WinXP. The behavior is the same regardless of which is the client and which is the fileserver, so it's not a Vista thing.
• The behavior is identical when running as a standard nonprivileged user and as an administrator.
• Not running in an AD domain.
• Same username and password on client and fileserver, so I can access the file without needing to use net use to supply credentials.

I'm sure this is going to be one of those "arrrgh" moments... What am I missing?

Answer 1

I'm not a CAS guru, but I suspect this may be due to the change in .NET 3.5 SP1 that allows code from a network share to run as Full Trust.

Edit: Brad Abrams states that a recompile/target is not needed to take advantage of this. I'd assume it works the same in reverse - that targeting 2.0 will not get you the old behaivor, if you have 3.5 SP1 on your machine.

An existing application does not have to be recompiled or changed in any way to take advantage of this. Your current 2.0 Applications will just work, you don't have to target anything new in 3.5..

I suppose a fresh (VM) install with only the 2.0 FX may be able to root this out as the cause.

Answer 2

The way the change works is that there is a new piece of evidence when launching a managed exe.When the exe is launched from the win32 CreateProcess API directly the managed exe is given full trust.

Of course, the .net configuration tool doesn't launch the exe, merely inspects it. This means that the evidence is different and affects the code group assigned to it. This in turn affects the permissions.

Pretty confusing.

More information can be found here:

msdn social

Brad Abrams blog