Exam 70-511: Interoperability with legacy Code Access Security in Windows Presentation Foundation 4.0

Objective: Implement security features of an application.

• This objective may include but is not limited to: configuring Software Restriction Policy (SRP); full trust and partially trusted security; interoperability with legacy CAS policy; User Account Control (UAC)

Code Access Security

link: https://msdn.microsoft.com/en-us/library/c5tk9z76(VS.100).aspx

From: Summary of Changes in Code Access Security

Link: https://msdn.microsoft.com/en-us/library/ff527276.aspx

In the .NET Framework version 4, code access security (CAS) has undergone major changes, with the purpose of simplifying the security system.

In earlier versions of the .NET Framework, the rights of a managed application were determined by security policy rules, which were set computer-wide to establish runtime settings.

Starting with the .NET Framework 4:

• Security policy is no longer in effect.

  • Permissions are still in use

  • Only the security policy system has been eliminated

• Access rights for applications are determined by two factors:

  • Permissions

    • Grant set established by the application domain

  • Transparency

    • All partial-trust applications are classified as transparent.

    • Transparent applications do not have to be concerned with security.

    • Transparency was first used for Microsoft Silverlight and has now been extended to all hosted environments.

• Desktop and local intranet applications are granted full trust

How the Security Model Works

• Each AppDomain has an associated permission set defined by the host in a hosted scenario.
  • The permission set is full trust for code that is not hosted
• Partial-trust code is always transparent
  • Partial-trust code cannot perform the actions prohibited for transparent code
• By default, full-trust code is critical unless it has been marked as being transparent.
  • Example:
    • If a desktop application is marked as transparent, it cannot call critical code, even though the desktop application has full trust
• Libraries may be exposed to partial-trust code both by the host and by the .NET Framework
  • These libraries contain a mix of transparent, critical, and safe-critical code
• The safe-critical code must demand appropriate permissions before using critical functionality
  • Example:
    • The File.Open method demands FileIOPermission before it opens a file
• The safe-critical code must also perform any other checks and validation before and after calls to critical functionality.
  • Example:
    • Exceptions and messages may have to be filtered before being passed to partially trusted code.
• Critical code has to assert the permissions it needs when it is called by partial-trust code
  • Critical code might be doing something that the partial-trust code is not allowed to do

What in the heck is Security-Transparent, critical or Self Critical Code?

This is deep, I have a trusty Dietel Developer Series book on C#2010 for Programmers which is overdue from the Microsoft library, let’s see what Dietel says on this very important part of programming:

Nothing

This book looks suspiciously like the College textbook without the homework problems, but if I look up Code Access Security or just the word Security in the index, nothing. 

What about Security-transparent, critical or self critical code? In over 1100 pages of tiny print, no mention in the index and I simply don’t have time to review the whole book.  Weird.

Look like I got more blog material!

Watch for more on security and unit testing in the future!