SecurityManager stubs return poor results

[AArnott]

SecurityManager.GetStandardSandbox returns null instead of a PermissionsSet that equates to full trust.
Other methods like XXXPermission.IsUnrestricted return false instead of true.

This is causing failures on .NET Core for code that would work on .NET Framework.

[danmoseley]

@GrabYourPitchforks any concerns? I think our intent was to behave as if we were always in full trust.

[danmoseley]

There's others, eg., ResolvePolicy probably ought to return new PermissionSet(PermissionState.Unrestricted); as well.

[jkotas]

I think our intent was to behave as if we were always in full trust.

That was one principle. Another principle was to try to avoid silently introducing security bugs if the code depends on CAS. That's why some of the stub methods throw instead of just being a no-op. For example, consider this code that somebody might have written using GetStandardSandbox:

        string url = "https://www.malware.com";

        Evidence e = new Evidence();
        e.AddAssemblyEvidence(new Url(url));
        PermissionSet ps = SecurityManager.GetStandardSandbox(e);
        if (ps.IsUnrestricted()) // This will return false in .NET Framework, even under full trust
        {
            ... download and run code from url ...
        }

If you make GetStandardSandbox to return unrestricted permission set, you will introduce security bug in this code.

[GrabYourPitchforks]

Honestly that's why I'd prefer all these methods to throw NSE. CAS has been broken for years and we don't want to encourage people to bring existing CAS-related code forward.

If we want the APIs to return something other than throw NSE then we should take this bug per Andrew and Jan's comments.

[danmoseley]

Do we expect the code as it is today to expose more security risk than .NET Framework 4.8 does with CAS disabled?

If so, maybe we should begin to throw in 5.0. But IIRC (from the analyses we did for .NET Standard) there are plenty of libraries that assert in quite a simplistic way and are perfectly happy if those asserts just succeed, and would then be broken and need modification.

Is the current state the best balance?

[GrabYourPitchforks]

@danmosemsft I agree this is probably the best balance. I've already spoken offline with Immo about CAS-related APIs being good candidates for his "better obsolescence" idea. Maybe that gives us a good place to start.

[danmoseley]

OK. @AArnott can the calling code use an alternative approach here?

[GrabYourPitchforks]

A tricky part of getting SecurityManager to return the correct value is that it would require re-introducing the logic within the Evidence class and other CAS-related types. That logic has by and large been ripped out of .NET Core because we have no good way of evaluating evidence. Evaluating evidence inappropriately could lead to the problems Jan mentioned above.

[AArnott]

Yes, I think we can remove the calling code.

[danmoseley]

Ok, closing