Code Access Security

1
Code Access Security: Motivation

• The traditional process-centric security model breaks down in a

component-oriented world. Code Access Security addresses
this issue by layering a component-aware security model over
any existing operating system security model

2
History

• Historically, security has been process-centric

– Each process is assigned a token by the system
– Token contains user identity and group identifiers
– When one process creates another, the token is duplicated
to the new process
– System worked reasonably well since one vendor generally
shipped all the code for an application

3
Figure 1.1: Monolithic applications

Alice

APP.EXE

APP.DLL

KERNEL32.DLL USER32.DLL GDI32.DLL

4
The Component Revolution

• Dynamically loaded components (ala COM) break a process-

centric model
– The COM revolution led to building processes from DLLs
– DLLs now built by multiple vendors
– Each DLL runs at the same level of privilege (process token)
– To sandbox a DLL, it must be run in a separate process,
which is expensive and painful to administer

5
Figure 1.2: Component-based applications

Alice

APP.EXE

FOO.DLL
BAR.DLL

QUUX.DLL ACME.DLL

BAZ.DLL

KERNEL32.DLL USER32.DLL GDI32.DLL

6
Authenticode

• Authenticode was a smokescreen

– Authenticode attempted to make component vendors
accountable
– Punitive solution, not a preventative one
– By the time you're in court, damage has already been done
– Even well-meaning components often have gaping security
holes due to weak implementations

7
Figure 1.3: Well-meaning, but ultimately bad code

void main() {
foo();
}

void foo() {
char buf[1024]; // surely this will be big enough!
readUserNameFromForm(buf);
logUserName(buf);
}

8
Code Access Security

• CAS layers component-centric security over the security model

of the OS
– CAS provides a preventative, rather than a punitive model
– Components can be physically prevented from doing bad
things
– Verifiable code isn't subject to buffer overflow attacks

9
Figure 1.4: CAS is layered on top of OS native security

Alice
HOST.EXE

FOO.DLL
BAR.DLL

QUUX.DLL ACME.DLL

BAZ.DLL
MSCORLIB.DLL

KERNEL32.DLL USER32.DLL GDI32.DLL

10
Security Policy

• Assemblies are granted permissions based on their origin. Code

Access Security (CAS) Policy dictates the permissions granted
to any assembly.

11
Permissions

• Permissions express details about sensitive operations

– Permission objects are used for two things: grants and
requests
– IPermission expresses this, and IsSubsetOf allows
comparison between requests and grants
– Permission objects are serializable to allow storage in policy
files
– PermissionSet allows grouping of different classes of
permissions
– Several built-in permission classes already exist
– Possible to extend with your own classes

12
Figure 1.5: The IPermission interface

namespace System.Security {
interface IPermission {
bool IsSubsetOf(IPermission target); // comparison

void Demand(); // request

void DemandImmediate();

IPermission Copy(); // formation

IPermission Intersect(IPermission target);
IPermission Union(IPermission target);
}
}

13
Figure 1.6: The ISecurityEncodable interface

namespace System.Security {
interface ISecurityEncodable {
void FromXml(SecurityElement elem);
SecurityElement ToXml();
}
}

14
Figure 1.7: The PermissionSet class

namespace System.Security {
class PermissionSet : ISecurityEncodable, ... {

bool IsSubsetOf(PermissionSet target); // comparison

void Demand(); // request

void DemandImmediate();

PermissionSet Copy(); // formation

PermissionSet Intersect(PermissionSet p);
PermissionSet Union(PermissionSet p);
IPermission AddPermission(IPermission p);

// other methods omitted for brevity

}
}

15
Figure 1.8: Some built-in code access security permission classes

DBDataPermission
PrintingPermission
MessageQueuePermission
DnsPermission
SocketPermission
WebPermission
EnvironmentPermission
FileDialogPermission
FileIOPermission
IsolatedStoragePermission
ReflectionPermission
RegistryPermission
SecurityPermission
UIPermission

16
Figure 1.9: Example: requesting a permission

using System.Security.Permissions;

class Test {
public void readSomeFile() {

// describe your request

IPermission request = new FileIOPermission(
FileIOPermissionAccess.Read,
@"c:\foo\bar\quux.txt");

// make the request

request.Demand(); // throws SecurityException on failure

// if we're still here, the demand succeeded!

}
}

17
Evidence

• The loader discovers evidence of the origin of code

– Evidence describes the code being loaded
– Used to determine the permissions granted to an assembly
– Evidence takes many forms
– Zone, URL, X.509 certificate, strong name, etc.
– Custom evidence also possible

18
Figure 1.10: Some built-in classes of evidence

Zone
Site
Url
Publisher
StrongName

19
Policy Levels

• On a given machine policy is arranged in three levels

– Machine policy file, administered by the sysadmin
– User policy files, administered by individual users
– Host policies, provided at runtime by the app hosting the
CLR
– Resulting permission set is intersection of all three levels

20
Figure 1.11: Policy levels

Machine

User Host

Intersection of results form

the set of allowed permissions

21
Code Groups

• Each policy level consists of a tree of code groups

– A code group maps a criteria to a set of permissions to grant
– Code groups are arranged in a tree
– A child code group will only be evaluated if the parent's
criteria was satisfied
– Allows non-programmers to combine criteria using boolean
logic

22
Figure 1.12: A policy level consists of a tree of code groups

Criteria

Permission Set

23
Figure 1.13: Modeling a boolean AND with two code groups

Criteria:
Publisher is ACME

Permission Set:
Nothing (empty)

Criteria:
Zone is Intranet

Permission Set: Read c:\acme

Foo Show dialogs
Read the clipboard

24
Figure 1.14: Modeling a boolean OR with two code groups

Criteria: Criteria:
Publisher is ACME Zone is Intranet

Permission Set: Permission Set:

Foo Foo

25
Declarative Permission Requests

• Each assembly can make declarative permission requests

– Assemblies can effectively filter permissions allowed by
policy
– Allows an assembly to state the minimum permission set it
does need
– Allows an assembly to refuse permissions it doesn't need
– Assembly-level attributes control these requests
– A PermissionSetAttribute that refers to a file is a good way to
go

26
Figure 1.15: Annotating an assembly with permission requests

using System;
using System.Security.Permissions;

[assembly: PermissionSetAttribute(
SecurityAction.RequestMinimum,
File="min_perm.xml")]
[assembly: PermissionSetAttribute(
SecurityAction.RequestOptional,
File="opt_perm.xml")]

class ep {
static void Main() {
Console.WriteLine("Hello World");
}
}

27
Figure 1.16: Creating a serialized permission set

// create the permissions you need

FileIOPermission p1 = new FileIOPermission(
PermissionState.Unrestricted);
RegistryPermission p2 = new RegistryPermission(
PermissionState.Unrestricted);

// group them into a single permission set

PermissionSet pset = new PermissionSet(
PermissionState.None);
pset.AddPermission(p1);
pset.AddPermission(p2);

// convert into XML

SecurityElement miniDOM = pset.ToXml();

// put it somewhere (file IO omitted for brevity)

Console.WriteLine(miniDOM.ToString());

28
Administering Policy

• CASPOL.EXE is used to administer machine and user policy

levels
– Can be used to read and modify policy
– Can be used to check the permissions assigned to an
assembly
– Requires administrators to read and write XML manually
– Expect better tools from either Microsoft or third party
vendors

29
The CAS Stackwalk

• Programmers often use layering to simplify code, but this often

opens up security holes as misuse of one layer can lead to the
compromise of another. Code Access Security guards against
these attacks via a stack walking mechanism.

30
The Luring Attack

• Attackers may try to lure trusted components into doing evil

things
– Evil components generally want to elevate their privilege
level
– Privilege escalation can occur by luring a more privileged
component
– One policy is that of isolation: don't let the components talk
to each other at all
– CAS takes a more benevolent approach by monitoring the
conversation
– The IStackWalk interface is the key abstraction here

31
Figure 1.17: The IStackWalk interface

namespace System.Security {
public interface IStackWalk {
void Assert();
void Demand();
void DemandImmediate();
void Deny();
void PermitOnly();
}
}

32
Demand and DemandImmediate

• A permission demand percolates up the call stack

33
Deny and PermitOnly

• Each stack frame can restrict its effective permission set

– Before making a call, you can restrict your permission set
– Deny is used when you know specific permissions you want
to remove
– PermitOnly is used when you know the set of permissions
you want to allow
– Generally you should avoid making these sorts of policy
decisions

34
Figure 1.18: Example: denying permissions before making a call

public void DoSomeWorkThenMakeCallback(CallbackDelegate d) {

// do some work...

// restrict our permission set before making the call

FileIOPermission p = new FileIOPermission(
PermissionState.Unrestricted);
p.Deny();

// make the call

d.HereIsTheCallback(); // won't be able to open files

// returning removes our stack frame (and the Deny)

}

35
Figure 1.19: How to remove CAS stack frame modifiers

// excerpt from class CodeAccessPermission

public static void RevertDeny();

public static void RevertPermitOnly();
public static void RevertAssert();
public static void RevertAll();

36
Assert

• Trusted components may need to specialize generic demands

– You can't make an omelet without breaking some eggs
– Assert allows a trusted component to do work that its caller
isn't allowed to do
– Trusted component demands a more specific permission
before asserting its own authority
– Example: controlled calls to unmanaged code are a fact of
life
– Assertion ultimately used to allow a more fine-grained policy

37
Figure 1.20: Deny versus Assert in a stackwalk

permissions granted to each assembly

A, B
A, C

call stack
A, C Deny A
A, B, C Assert B
A, B, C
A, B, C
Demand A Demand B Demand C
denied granted denied

38
Bootstrapping

• Top of stack permissions are assigned at AppDomain creation

time
– Top-of-stack permissions are determined by the AppDomain
creator
– Allows control over entire AppDomain

39
Figure 1.21: Setting top-of-stack permissions for a new AppDomain

object[] hostEvidence = { new Zone(SecurityZone.Internet) };

Evidence myEvidence = new Evidence(hostEvidence, null);
AppDomain newDomain = CreateDomain("MyNewDomain", evidence);

40
Summary

• CAS provides a component-aware security model

• Security policy can be configured per machine, user, or host
• Loader discovers evidence when loading an assembly
• Evidence is input to policy, result is permissions for an assembly
• CASPOL used to read and write policy
• Demand causes a stack walk to prevent luring attacks
• Assert is used to convert generic demands to more specific
ones

41