The .NET Framework Security Model

Introduction

When I was first faced with the .NET Framework security and cryptography fist, I noticed that most of the quick-start articles sufferes from lots of low-level details and explanations of the nuts and bolts of .NET Framework Security.

But for the first time, I needed a brief, easy to understand and remember tutorial, instead. So, actually this is not an article. This is rather a bird's-eye overview of the .NET Framework security model, with visual illustrations.

Security concepts

You can implement the security model in your applications in a declarative and/or an imperative way. In most cases, you should prefer declarative security, and implement the security model only when some application security issues can be known only at runtime.

Sample of declarative security:

[assembly : FileDialogPermissionAttribute(
            SecurityAction.RequestMinimum, 
            Unrestricted=true)]

Sample of imperative security:

FileDialogPermission fileDlgPermission = new 
       FileDialogPermission(PermissionState.Unrestricted);
fileDlgPermission.Demand();

if (myDlgForm.ShowDialog() == DialogResult.OK)
    MessageBox.Show(myDlgForm.FileName);

.NET Framework Security Model

Code Access Security (CAS)

Permissions

Code groups

CLR examines all code groups in the hierarchy. When the code group is marked as Exclusive, then the CLR stops checking for group membership. Next, the CLR determines the permission sets for each code group. If the code is a member of the code group that is marked as Exclusive, only the permission set of that code group is taken into account, otherwise the CLR calculates the permission as a Union of all permission sets of all code groups that the running code is a member of.

Computing Permissions

Any code group can have a LevelFinal property; in that case, the CLR stops its examinations there.