Microsoft 'NET Run Time Security Paddy Srinivasan Development Consultant Premier for ISVs Microsoft

1
Microsoft .NET Run Time SecurityPaddy
Srinivasan Development ConsultantPremier for
ISVsMicrosoft Corporation
2
Agenda

• Introduction to Microsoft .NET Framework
  security
• Code access security
• Permissions
• Declarative and imperative security
• Stack walks
• Policy management
• Code groups and permission sets
• Policy and grants
• Evidence

3
.NET Framework Security

• Evidence-based security in the CLR
• Partially-trusted code (sandboxed code)
• Authorization of code according to policy
• Cryptography
• Encryption, digital signatures, hashes, RNG
• XML Web Services security
• Today channel-oriented authn authz
• Future message-oriented (signed encrypted SOAP
  exchanges)

4
CLR Security Design Goals

• Robust security system for partially-trusted
  mobile code
• Adds on to user-level security in the operating
  system
• Makes it easier for
• Developers to write secure applications
• Standard libraries implement security checks for
  exposed resources
• Easy to perform security checks in user code
• Administrators to express their policies
• Fine-grained authorization models
• System is completely extensible
• End users to work securely
• No run-time security decisions (end-user UI)

5
Key Semi-Trust Scenarios

• Operating system security is based on user rights
• CLR security, added on top of operating system
  security, gives rights to code

6
Code Access Security

• Permissions
• Objects that represent specific authorizations
• Policy
• Determines what code is permitted to do
• Set of permissions to grant to an assembly
• Evidence
• Inputs to policy about code, from multiple
  sources
• All three are fully extensible

7
Permissions

• A permission object represents a specific
  authorization, such as access to a resource
• permission to do something
• A permission grant is an authorization given to
  an assembly (code)
• this code is authorized to do something
• A permission demand is a security check for
  corresponding grants
• is something permitted? (else, raise exception)

8
Standard .NET Permissions

• Framework permissions for resources
• DataAccess EventLog
• DirectoryServices Environment
• Registry Reflection
• FileIO FileDialog
• IsolatedStorage Printing
• MessageQueue Socket
• DNS Web

9
Requesting Permissions

• Requesting permissions
• Done by callers
• Implemented using attributes
• Stored in assembly manifest
• Three kinds minimum, optional, and refused
• Not mandatory

10
Permission Request

• Request (minimum, optional, refused)
• If none, code receives the maximum that the
  policy gives
• Requesting permissions is one way

assemblyUIPermissionAttribute
(SecurityAction.RequestMinimum,
WindowUIPermissionWindow.SafeSubWindows) assem
blyFileIOPermissionAttribute (SecurityAction.Requ
estOptional,All"C\\") assemblySecurityPermis
sionAttribute (SecurityAction.RequestRefused,Unman
agedCodetrue)
11
Demanding Permissions

• Demanding permissions
• Done by the server objects
• Demand callers to have certain permissions
• Ensures that only authorized callers can run your
  code
• Demanding permissions are optional

12
Declarative Demands

• Declarative demands
• Part of a methods meta data
• Implemented with custom attributes
• JIT converts the annotation to a check

FileIOPermission(SecurityAction.Demand, Write
c\\temp) public void foo() // class does
something with c\temp
13
Imperative Demands

• Imperative demands
• Security check initiated by your code
• Create and initialize permission object and call
  Demand()

using System.Security.Permissions FileDialogPermi
ssion MyPermission new FileDialogPermission
(PermissionState.Unrestricted) MyPermission.Dema
nd()
14
Permission Enforcement

• Most permissions are code-access permissions and
  have stack-walking semantics
• A demand for a code-access permission must be
  satisfied by grants to every stack frame above
  the demanding frame
• Stack-walking is a defense against luring attacks
• Less-trusted code tricking more-trusted code into
  performing protected operations
• Stack walk modifiers can change the default
  semantics

15
Stack Walk

• Demanding a permission performs stack walk
  checking for related grants
• Run time walks the stack to determine the grants
  at each level
• Support for dynamic stack modifiers
• Override the security stack walk dynamically
• Assert
• Deny
• PermitOnly

16
Stack Walk Behavior
Each assembly has a set of corresponding grants
Assembly A1
Call stack grows down
G1
P
Assembly A2
G2
P
G3
P
Method in assembly A4 demands a permission P
P is compared with grants of all callers on the
stack above A4
G4
P
17
Code Group

• Two linked rules
• What assemblies are a member?
• What permissions should they be granted?
• Organized into a hierarchy
• Membership in the group is decided by a Boolean
  function that evaluates sets of Evidence
• Membership conditions can do whatever computation
  they want (for example, independent validation of
  Evidence objects)

Code group
18
Code Groups and Permission Sets
Code Groups
Permission Sets

• Logical grouping of code
• Cryptographic hash
• Software publisher
• Strong name
• URL
• Zone

• Permissions associated with each code group

• Nothing
• Execution
• Internet
• Intranet
• Full trust

19
Hierarchical Policy Levels

• CLR supports multiple ordered policy levels for
  administration
• Enterprise common policy throughout an
  organization
• Computer policy for all users of a particular
  computer
• User policy specific to logged-in user
• Effective policy is the intersection of all levels

20
Sample Policy Level

• Example MS.Money on local intranet
• Member of three groups (highlighted)
• Granted permissions P1 ? P2 ? P7 ? P4

All Code
All Code
P1
Publisher Microsoft
Zone Internet
Zone Local Intranet
Site XYZ.COM
Publisher Microsoft
Zone Local Intranet
P5
P
P2
P4
Name MS.Office
Name MS.Money
Site localweb
Publisher Corp. Admin
Name MS.Money
P8
P9
P6
P7
21
Evidence

• Evidence is the input to policy
• Example info about a code assembly
• Shared names
• Publisher identity
• Location of origin (URL, zone, site)
• Evidence is completely extensible
• Any object can be a piece of evidence
• Only affects grants if there is a code group
  membership condition that cares about it!

cryptographicallystrong
22
Examples of Evidence
23
Host and Application Input to Policy

• Hosts can influence policy
• Hosts specify implicitly trusted evidence
• Custom membership conditions can interface with
  other authorization systems
• Example ASP/ISP application hosting
• Application domains can limit policy for other
  domains they create
• Example Microsoft SQL Server user-defined
  assemblies

24
Extending the Policy System

• Custom permissions
• Application-defined authorization for a resource
• Easy integration with policy
• Custom code groups and membership conditions
• Implement new code group logic
• Dynamic permission set computation
• Change default combining logic
• Custom evidence
• Create embedded evidence (for example,
  certifications)
• Evidence from trusted hosts

25
Putting It All Together
Assembly A3
Security Policy
Policy Evaluator
26
Summary Customer Experience

• End user
• Safely runs more powerful code without high risk
• Consistent experience with scripts, .exe files,
  and controls
• Safe defaults no run time trust decisions for
  users
• Administrator
• All settings in one place easy to customize
• Powerful policy model
• Security administration tool
• Developer
• Can focus on application logic most security
  comes for free
• Easy to use and extend when necessary, such as
  protecting a new shared resource

27
Additional Resources

• .NET Security
• http//msdn.microsoft.com/nhp/Default.asp?contenti
  d28001369frametrue
• Security in .NET Enforce Code Access Rights with
  the Common Language Runtime
• http//msdn.microsoft.com/msdnmag/issues/01/02/CAS
  /CAS.asp
• .NET Framework Developer's Guide Securing
  Applications
• http//msdn.microsoft.com/library/en-us/cpguide/ht
  ml/cpconsecuringyourapplication.asp?frametrue

28

• Thank you for joining us for Todays Microsoft
  Support
• WebCast.
• For information on all upcoming Support WebCasts
  and
• access to the archived content (streaming media
  files,
• PowerPoint slides, and transcripts), please
  visit
• http//support.microsoft.com/WebCasts
• We sincerely appreciate your feedback. Please
  send any
• comments or suggestions regarding the Support
• WebCasts to supweb_at_microsoft.com