Control Code Privileges

A quick refresher about the security policies of the .NET Framework:

  1. Security Policy Levels
  2. A Hierarchy of Code Groups
  3. Named Permission Sets associated with Code Groups
  4. Evidences of an assembly
  5. Application Domain hosts that provide evidences to the CLR

Don’t worry if you can’t recall all of these, check out the MSDN link at the bottom, called Security Policy Management. This post will be about the namespace System.Secuirty.Policy. This namespace contains code groups, membership conditions and evidences. The previous three types are used to create the rules applied by the CLR. Evidence classes are the inputs of security policies, and the membership conditions are switches of it. The policy levels and code groups are the structure of a policy hierarchy. Code groups are the encapsulation of a rule and are members of the policy level.

Continue reading

Advertisements

Improve the Security of a .NET Framework Application with CAS

The .NET Framework introduces a new layer of security, called Code Access Security. This layer lives on top of the OS security, and lets you control what a given assembly can and can’t do, just like the OS lets you define the rights of a user or group.

Before we dive into the details, there’s something (which may seem obvious at first, but is a particularly good thing to remember on the exam): whatever permissions you grant to a code, it will never have more rights than the user who runs it (just recall ASP.NET and IIS).

In the previous post, I wrote about permissions. The first important layer of CAS is the control of them. There are default permission sets, defining what an assembly can do. They are as follows:

FullTrust Exempts an assembly from CAS checks.
SkipVerification Enables an assembly to bypass permission checks.
Execution Enables an assembly to solely run.
Nothing No permissions granted. Not even enough to run the given assembly.
LocalIntranet The main restriction is that the assembly is not allowed to tamper with the file system, only through file dialogs.
Internet A restrictive permission set, but safe.
Everything Grants all permissions, but still checks the assembly.

  Continue reading

Control Permissions for Resources

The classes related to controlling permissions and access for resources are live in the System.Security.Permissions namespace. There are a whole lot of permission classes for imperative security access settings, and each of them has its declarative attribute counterpart. There are three major categories of them:

  • Code access permissions
  • Identity permissions
  • Role-based permissions

Code access permissions represents access to a given resource or the ability to perform a specific operation. For example, FileDialogPermission and RegistryPermission are classes which fall into the category of code access permission.
Continue reading

Implement a Custom Authentication Scheme

Now this one is short will be short and will have nothing to do with the title. I’ve found four enumerations in the System.Security.Authentication namespace. The most important of these is the SslProtocols enumeration. It has five possible values. You should know that the Ssl values (Ssl2 and Ssl3) are provided only for backward-compatibility and they are all superseded by the Tsl protocol. The fifth value is None, and it speaks for itself. Here’s a repeat for a better layout of this blog:

  • SSlProtocols enumeration:
    • Default (Ssl3 or Tsl will be used)
    • None
    • SSl2
    • Ssl3
    • Tsl

I forgot to mention that this enumeration controls which SSL protocol should be used for a given SslStream. Just in case if someone didn’t figure it out.
Continue reading

Access and Modify Identity Information

I was evading the topic of security ever since I began posting my notes. It had a good reason: I’ve never worked with it. So I’d like to apologize here and now for the future mistakes in the following series of posts.

The first security-related objective we’ll revise is the accessing and modifying of the identity information. You can access the currently working user account (the entity under the current thread executes. There won’t be any calls to the stack to find an appropriate identity in it.). To achieve this, you’ll consider using two classes: the GenericIdentity and the GenericPrincipal classes. These classes have counterparts designed for using the Windows authentication services (like Active Directory). They are called WindowsIdentity and WindowsPrincipal respectively.

Of course, you can implement your custom Principal/Identity classes. In this case, your yet-to-come classes must implement IPrincipal or IIdentity. Let’s see a code sample on how to access the current user:

WindowsIdentity theIdentity = WindowsIdentity.GetCurrent();
if(theIdentity.IsAuthenticated)
  Console.WriteLine(“Good news, you are authenticated!”);
GenericIdentity myCustomIdentity = new GenericIdentity(theIdentity.Name, theIdentity.AuthenticationType);

Continue reading