Code Access Security

1
Code Access Security

• CS 795

2
Terminology--CLR

• Common Language Runtime
• The .NET Framework provides a runtime environment
  which runs the code and provides services that
  make the development process easier.
• The CLR sits at the very heart of managed code.
• It is the generalized multi-language, reflective
  execution engine on which code originally written
  in various languages runs.
• At a higher level, CLR is simply an engine that
  takes in Intermediate Language (IL) instructions,
  translates them into machine instructions, and
  executes them.
• Although the common language runtime provides
  many standard runtime services, managed code is
  never interpreted.
• A feature called just-in-time (JIT) compiling
  enables all managed code to run in the native
  machine language of the system on which it is
  executing. The CLR shares much in common with a
  traditional operating system.

3
Terminology---Managed/Unmanaged Code

• Managed code is code that has its execution
  managed by the .NET Framework Common Language
  Runtime.
• The necessary information is encoded in an
  Intermediate Language (IL) and associated
  metadata, or symbolic information that describes
  all of the entry points and the constructs
  exposed in the IL (e.g., methods, properties) and
  their characteristics.
• There are many languages to choose from, since
  there are nearly 20 different languages provided
  by third parties everything from COBOL to Camel
  in addition to C, J, VB .Net, Jscript .Net,
  and C from Microsoft.
• Before the code is run, the IL is compiled into
  native executable code. And, since this
  compilation happens by the managed execution
  environment (or, more correctly, by a
  runtime-aware compiler that knows how to target
  the managed execution environment), the managed
  execution environment can make guarantees about
  what the code is going to do. It can insert traps
  and appropriate garbage collection hooks,
  exception handling, type safety, array bounds and
  index checking, and so forth.
• Unmanaged executable files are basically a binary
  image, x86 code, loaded into memory. The program
  counter gets put there and thats the last the OS
  knows. There are protections in place around
  memory management and port I/O and so forth, but
  the system doesnt actually know what the
  application is doing. Therefore, it cant make
  any guarantees about what happens when the
  application runs.

4
Terminology--Assembly

• Assembly---Code that the common language runtime
  (CLR) executes.
• Library assembly (contains classes others can
  use) cannot be executed
• Executable assembly
• Windows executable assembly---specific to GUI
  applications

5
Terminology---Strong Names

• Strong name Assemblies (especially the shared
  ones) may have a strong name. Strong name
  consists of assemblys
• name, version, culture metadata,
• Cryptographic public key---cryptographic key
  pairs are randomly created the private key is
  used to generate the digital signature and the
  public key is used to later verify it
• Digital signature---based on hash code generated
  on the contents of the assembly
• Considered as a unique identification for an
  assembly.
• Creating and verifying strong names see pages
  23-24, 26 (OReilly)

6
Terminology-SPC

• Software Publisher Certificate (SPC) Provide
  identity of the assembly publisher
• Signcode scheme---using this a digital signature
  is created using the private key components of
  the certificate and is embedded into the assembly
  along with the public key component of the SPC
• Makecert sv MyPrivateKey.pvk TestCert.cer
  creates a certificate with a public key and
  stores it in TestCert.cer corresponding private
  key is stored in MyPrivateKey.pvk
• Cert2spc TestCert.cer TestSPC.spc
• Signcode spc TestSPC.spc v MyProvateKey.pvk
  SingleFileAssembly.dll

7
Terminology-GAC

• GAC Global Assembly Cache
• If an assembly is shared by several applications,
  it can be installed into the GAC.
• It is a machine-wide store of shared assemblies
• Why place it in GAC?
• .Net framework automatically looks for an
  assembly in GAC so no need to configure to find
  it
• File security---tamper proof
• Simplify administration
• Multiple versions may exist
• gacutil /i SingleFileAssembly.dll ---install a
  file into GAC
• gacutil /l lists contents of GAC
• gacutil /l SingleFileAssembly ---lists the
  attributes of this file
• gacutil /u SingleFileAssembly ---to uninstall

8
TerminologyApplication Domain

• Logical containers within CLR that provide an
  isolation boundary for an application
• Similar to protection provided by processes in a
  Unix environment---no sharing of address space,
  etc.
• It is possible for a single process to run
  multiple applications without any boundary
  violations
• Assemblies within an application may be isolated
  from each other

Process
CLR
App Domain 2
Assembly3
9
More on Application Domains and Security

• Assembly evidence and identitywhen an assembly
  is loaded into an app domain, we can specify
  additional evidence to apply to the
  assembly---evidence determines the permissions
  granted by CLR to the assembly
• Application domain evidence and identity--when an
  application domain is created, it can be assigned
  some evidence CLR grants permissions to an app
  domain based on the evidence an action by an
  assembly is controlled both by assembly
  permission set an dapp domain permission set.
• App domains and security policy---while the
  enterprise level, machine level, and user level
  security policy levels are fixed, app domain
  security policy may be defined programmatically
• App domains and role-based security By default,
  the app domain through which a thread runs
  defines the principal on whose behalf the thread
  acts.
• App domain and isolated storage This is based on
  the identity of the assembly and the app domain
  in which the assembly is loaded.

10
TerminologyRuntime Hosts

• While CLR provides an execution environment for
  managed code, we need software to first RUN CLR
• Unmanaged code that loads and bootstraps CLR is
  called a Runtime host
• .Net Framework comes with three built-in runtime
  hosts
• ASP.Net uses a single CLR to run all ASP.Net web
  applications each web application is loaded into
  a separate application domain
• Internet Explorer uses a single CLR that executes
  all downloaded controls one application domain
  for each web site from which controls are
  downloaded
• Windows shell also can run CLR. It creates a
  single application domain that the executable
  assembly and all refernced assemblies are loaded
  to.

11
What is CAS?

• A means to assign identity or evidence to .Net
  assemblies
• User identities are not in this picture only
  assembly identities
• Code that is running may be denied access to a
  resource
• Suitable for environments where partially trusted
  code runs

12
More on CAS

• Authentication Deals with assembly evidence (and
  not Windows principals)
• Authorization Not related to OS-level objects
  instead they concern with standard application
  tasks such as accessing a database via an OLEDB
  provider or a resource on the Internet via a URL
• CAS permissions are directly attached to
  assemblies at load time

13
CAS Evidences for an Assembly

• Assembly inner (fixed) properties (e.g., assembly
  Strong Name or Publisher) and assembly origin
  (variable) information (e.g., URL, Site, Zone)
• .Net Built-in evidences (automatically evaluated
  and attached to the assembly by the CLR loader
  when referenced the 1st time)
• Application Directory Assembly origin
• Hash (Cryptographic hash) Within assembly
• Publisher (Authenticode signature) Within
  assembly
• Site (Site of origin http//www..) Assembly
  origin
• Strong name (cryptographically strong) Within
  assembly
• URL (URL of origin) Assembly origin
• Zone (Zone of origin such as internet
  zone) Assembly origin

14
Application Domain and Assembly Evidence

• CLR exposes methods to enable users create
  application domains or load assemblies
  explicitly. At this time it allows us to modify
  the evidence set (add new evidence or override
  evidence provided by CLR)
• Nothing can be done when it is loaded
  automatically by the CLR
• BCL base class library
• Creating a new evidence set object
• Evidence ev AppDomain.CurrentDomain.Evidence
• Zone z new Zone(SecurityZone.Internet)
• ev.AddHost(z)
• AppDomain myappdomain AppDomain.CreateDomain(my
  appdomain, ev)
• For an assembly, CLR provides evidence but we can
  override it
• Zone z new Zone(SecurityZone.Internet)
• ev.AddHost(z)
• Myappdomain.ExecuteAssembly(http//localhost/cas/C
  onsoleApplication1.exe, ev)

15
CAS Permissions

• .Net BCL comes with a list of built-in permission
  classes, one for each resource or service it
  provides access to
• System.DirectoryServices.DirectoryServicesPermissi
  on
• System.NET.DnsPermissions
• System.EnvironmentPermission
• System.Diagnostics.EventLogPermission
• System.Security.SecurityPermissions
• System.Data.OledbPermission
• Many more
• SystemPermissions class is used to allow
  permission to different disparate actions such as
  assembly evidences, creating application domains,
  and calling into unmanaged code

16
CAS Policies

• Three levels of security policies Enterprise,
  Machine, User (Fixed)
• It is also possible to define an
  application-specific policy and inject it into a
  newly created application domain
• Final permissions granted by the CAS to an
  assembly will be those granted in the
  intersection of the permissions
• The three policy configurations are stored in XML
  files
• ltWinDirgt\Microsoft.NET\Framework\ltversiongt\config\
  enterprisesec.config
• ltWinDirgt\Microsoft.NET\Framework\ltversiongt\config\
  security.config (for M/C)
• ltDocuments and Settings Pathgt\ltUsernamegt\Applicati
  on dataMicrosoft\CLRSecurity Config\ltversiongt\secu
  rity.config

17
Permission Sets and Code Groups

• Permission Set named set of permissions
  registered in a specific security policy.
• Membership condition A specific value of an
  evidence type e.g., ZoneInternet
  URLhttp//..
• Code Groups Building blocks of security
  policies. It is an association between a
  membership condition and a permission set.
• When an assembly evidence contains an evidence
  entry matching the code group membership
  condition, that assembly is a member of the code
  group, and thus permission set assigned to the
  code group is granted to the assembly
• Example classes UnionCodeGroup, NetCodeGroup,
  FileCodeGroup
• Example Suppose a Code Group B has the
  membership condition ZoneIntranet and
  Permission Set Everything. Suppose an assembly
  A has the following evidence set Zone X, Hash
  Y, Strong Name Z. So if X Intranet, then
  Assembly A is will be granted the Permission set
  of Everything.
• Built-in Permission Sets FullTrust,
  SkipVerification, Execution, Nothing,
  LocalIntranet, Internet, Everything
• By Default, FullTrust and Everthing or identical
  permission sets. However, FullTrust may have
  additional custom permissions, if defined.

18
Policy Structure Object Model

• Enables us to
• Navigate along the code group structure, and
  modify it
• Get and Set a groups membership conditions and
  permission set
• Resolve membership conditions against an assembly
  evidence, and
• So on
• RootCodeGroup property of a PolicyLevel object
  provides acces sto the root code group object of
  the policy. From that, we can get an enumerator
  to access its child group uisng Children
  property, and so on.
• Ex
• IEnumerator policyenumerator SecurityManager.Pol
  icyHierarchy()
• While (policyenumertaor.MoveNext())
• PolicyLevel aPolicyLevel (PolicyLevel)
  Policyenumerator.Current
• CodeGroup rootcodegroup aPolicyLevel.RootCodeGro
  up
• Debug.WriteLine(rootcodegroup.name)

19
Policy Evaluation

• Complex due to the hierarchical nature of code
  groups in a CAS policy
• The order of execution Enterprise, Machine, and
  User, and app domain.
• Result is permissions granted to an assembly by
  intersecting permissions granted by each policy

20
CAS and ASP.Net Applications

• In the most common scenario ASP.Net applications
  are deployed in IIS virtual directory thus
  according to CAS, ZoneMyComputer evidence value.
  Thus, FullTrust permission set is granted to
  ASP.Net assemblies (as a default)
• Exception 1 Within an ASP.Net page, an assembly
  is downloaded from a URL (or UNC) CAS assigns
  limited permissions developers will have to
  modify security policy config to provide
  additional permissions if needed.
• Exception 2 IIS Virtual directory is mapped to a
  UNC path. Here, ASP.Net assemblies are loaded
  with intranet permission set they may not be
  sufficient to run an assembly

21
CAS Limitations

• CAS can perform access control only on managed
  code
• For security, do not allow calls to unmanaged
  assemblies
• Do not load from ZoneMyComputer .Net
  applications that we do not trust
• As long as Windows allows unmanaged code to run,
  nothing will prevent a virus from modifying
  security policies (XML files)
• To set a permission set from Nothing to
  FullTrust.
• For CAS to be secure, a robust ACL permission
  policy is essential.

22
Security Requests

• This takes place during the last stage of the
  assembly load time phase
• By placing security requests on assembly
  metadata, we can notify CAS about some
  permissions that we wish to associate with the
  assembly Request minimum (if these are not
  there), dont load Optional needs (needed but
  dont abort loading if they are absent) Refuse
  permissionsdont give these
• By default, optional permissions are all
  permissions. Thus, by specifying optional, we are
  reducing the scope.
• By placing the requirements in metadata, they can
  be viewed with the permission tool (Permview.exe)
  and can adjust security policies
• assembly FileIOPermission(SecurityAction.Request
  Minimum, Allc\temp)
• assembly SqlClientPermission(SecurityAction.Requ
  estMinimum, Unrestrictedtrue)
• Granted permissions (policies granted
  permissions) intersect (requested minimum union
  requested optional)-(refused permission)
• Alternately, built-in types
• assembly PermissionSet(SecurityAction.RequestMin
  imum, NameFullTrust)
• (or Internet, LocalIntranet, SkipVerification)

23
Run-time Security Demands

• Demand, Assert, Deny, PermitOnly
• Declaratively (via attributes) or imperatively by
  programmatic settings.
• Demand---Request CLR to perform the stack walk
  process
• FileIOPermission(SecurityAction.Demand,
  Readc\\
• Public class Class1
• public void dowork()
• SocketPermission sockperm new
  SocketPermission(NetworkAccess.Connect,TransportTy
  pe.Tcp,www.cs.odu.edu)
• sockperm.Addpermission (SocketPermission(Net
  workAccess.Connect,TransportType.Tcp,www.cs.odu.ed
  u)
• sockperm.Demand()

24
More on Demand()

• If an assembly demands a permission it has not
  been granted, no exception is thrown!!
• When a declarative demand fails, an exception is
  thrown to the direct caller
• When an imperative demand fails, an exception is
  thrown within the method call demanding the
  permission
• When a Demand call is encountered at run time,
  CLR picks up the demanded permission object and
  performs a stack walk along the assembly call
  chain.

25
Modify stack walk--Assert()

• To stop stack walking and force a positive
  outcome of the Demand call.
• Ex An assembly accesses the windows registry via
  Microsoft.Win32.Registry class, which raises
  security demands at runtime. The assembly may not
  require all callers to have this ability.
• Declaratively
• PermissionSet (SecurityAction.Assert, Name
  FullTrust)
• Imperatively
• Public void dowork()
• FileIOPermission x new FileIOPermission
  (FileIOPermissionAccess.Read, c\\)
• x.Assert()

26
Modify Stack Walk Deny()

• Deny ha sthe opposite effect to Assert
• It is used in situations where we want to
  prematurely stop a stack walk, and force a
  negative outcome.
• Of course, the assembly calling Demand must be
  granted the demanded permission being checked by
  the stack walk.
• Example (at class level) Denying permission to
  call an unmanaged code
• SecurityPermission(SecurityAction.Deny,
  UnmanagedCodefalse)
• Public class Form1

27
Modify Stack--PermitOnly

• It is like inverted
• Here, we have to specify what permissions will
  not determine a negative outcome (or continue
  stack walk unaffected).
• public MethodB()
• try
• FileIOPermission p new FileIOPermission(Permissi
  onState.Unrestricted)
• P.PermitOnly()
• catch (SecurityException se) // Handle
  exception
• Here, MethodB will cause a stack walk to
  terminate if methods further down the call stack
  demand any permissions other than a
  FileIOPermission.
• PermitOnly is ignored for a permission not
  granted because a demand for that permission will
  not succeed. However, if code lower on the call
  stack later calls Demand for that permission, a
  SecurityException is thrown when the stack walk
  reaches the code that tried to call PermitOnly.
  This is because the code that called PermitOnly
  has not been granted the permission, even though
  it called PermitOnly for that permission. The
  call stack is typically represented as growing
  down, so that methods higher in the call stack
  call methods lower in the call stack.

28
References

• http//www.codeproject.com/dotnet/UB_CAS_NET.asp
• http//www.codeguru.com/columns/DotNet/article.php
  /c9253/
• http//www.codeguru.com/columns/dotnet/article.php
  /c9393/
• http//www.developer.com/security/article.php/3483
  866
• http//msdn2.microsoft.com/en-us/library/87x8e4d1.
  aspx
• http//www.code-magazine.com/Article.aspx?quickid
  0405031
• www.theserverside.net/articles/
  content/PracticalDotNet2/PracticalDotNet2Ch6.pdf
• geekswithblogs.net/claeyskurt/Rss.aspx