Friday, 27 March 2009

Code Access Security (CAS) in .Net 3.5 (+ Other Security Bits)

This entry is actually the first in a write up of my notes from previous DevWeeks. Although from 2008, this is still relevant today...

These notes follow on from Dominick Baiers talk on this subject at DevWeek 2008.

Code Access Security & Sandboxing

Most of the important base features were added in 2.0, including a simple sandboxing API, security transparency and manifest based activation. These have been used in several current and future technologies such as ClickOnce, XBAP, and SilverLight.


Sandboxing is all about loading code dynamically yet restricting what it can and cannot do. This is supported using the AppDomain class with restricted permissions. The permissions that the code in the sandbox would use were defined by the permission set in Code Access Security (CAS).

Code Access Security Overview

CAS defines permissions and permission sets that represent the right to access various system resources. The permissions are grouped into security policies by associating them with groups of code. It allows code to request the permissions it requires in order to run, as well as the permissions that would be useful to have, and specifies which permissions the code must never have. The restrictions are enforced at run time.

When a method that is called demands a permission, CAS traverses the stack of assemblies up, checking if the method is allowed. The diagram below illustrates this:

Setting up permissions and policies however in CAS was very cumbersome and not very readable without in depth knowledge of CAS, and even then a challenge.


The CAS model has now been simplified for sandboxing, so that the PolicyLevel attribute is no longer required, and that the AppDomain is independent from the security policy (which is a very painful document to work with). Instead, loaded assemblies either get permissions specified in grantSet or full trust if part of fullTrustAssemblies list.


Windows Security Integration

Much of the work to provide Windows security integration was done in 2.0 with SIDs, ACLs and tokens.


Role based security has been integrated since 1.0 using IIdentity and IPrincipal along with Thread.CurrentPrincipal and PrincipalPermission. 3.0 introduced authorisation systems based on claims (Claim type, Resource, Right) which are grouped into claim sets. A claim set has an issuer and the issuer itself is a claim set.


A new "convenience" library has been added for common tasks called System.DirectoryServices.AccountManagement. This allows amongst other things:


    • Adding/modifying/deleting user/group/machine accounts

    • Password validation

    • "is user x in group y" scenarios


It supports local, domain and ADAM user stores.



The symmetric cryptography and hashing algorithms have been updated in 3.5.


Also, support has been added for Crypto Next Generation (CNG) API, which is the next generation of crypto standards which are compliant with the NSA "Crypto Suite B" set, and elliptic curve based algorithms.


Note, the new API is only supported by Vista and Windows Server 2008 however


Network Protocols

The most important additions here were made in 2.0, which are SslStream and NegotiateStream, which allow the layering of SSL and SPNEGO over arbitrary network streams. This gets used by higher level frameworks live WCF.


Two new secure protocols were also added in 3.5 which were Named Pipes (anonymous and named) and Peer technologies including peer to peer (P2P), peer name resolution protocol (PNRP) and people near me (PNM)



New support is added for Event Tracing for Windows (ETW) and Windows Eventing 6.0 with new classes including EventSchemaTraceListener, System.Diagnostics.Eventing and System.Diagnostics.Eventing.Reader.


Windows Management Instrumentation (WMI) support has also been rewritten under System.Management and System.Management.Instrumentation.

No comments:

Post a Comment