Presentation is loading. Please wait.

Presentation is loading. Please wait.

Understanding.NET Framework Security David LeBlanc Microsoft Office.

Similar presentations


Presentation on theme: "Understanding.NET Framework Security David LeBlanc Microsoft Office."— Presentation transcript:

1 Understanding.NET Framework Security David LeBlanc Microsoft Office

2 Agenda.NET Framework Security Fundamentals.NET Framework Security Fundamentals Evidence Evidence Permissions Permissions Policy Policy.NET Framework security administration.NET Framework security administration Needed for setup Needed for setup When to use.NET Framework vs. core OS security When to use.NET Framework vs. core OS security

3 Why Is This Important? Understanding managed code security will help you make better decisions about when to use managed vs. unmanaged code Framework security can cause bugs Framework security can cause bugs Code running locally isn’t the same as code running from a share Code running locally isn’t the same as code running from a share

4 What.NET Is and Isn’t.NET IS a great new toolset.NET IS a great new toolset Can be used to solve previously unmanageable security problems Can be used to solve previously unmanageable security problems Largely eliminates buffer overruns Largely eliminates buffer overruns Allows a system or host application to restrict the capabilities of managed code Allows a system or host application to restrict the capabilities of managed code

5 .NET IS NOT a Silver Bullet A majority of security mistakes are language- independent A majority of security mistakes are language- independent Bad design is still bad design Bad design is still bad design New capabilities provided by.NET can be misused New capabilities provided by.NET can be misused New, improved ways to make security mistakes! New, improved ways to make security mistakes! Code running as fully trusted is just as dangerous as a native binary! Code running as fully trusted is just as dangerous as a native binary!

6 User and Code Identity Security Classic OS security is based on limiting the capabilities of a user or group Classic OS security is based on limiting the capabilities of a user or group Still an effective mechanism Still an effective mechanism Does not help when code is either untrusted or semi-trusted Does not help when code is either untrusted or semi-trusted Code Identity Security Code Identity Security Allows a user or admin to define the level of trust granted based on things we know about the code Allows a user or admin to define the level of trust granted based on things we know about the code To be most effective, use both approaches together To be most effective, use both approaches together

7 How Permissions Are Resolved Assembly Hosting App Domain Policy Evidence Permissions

8 How Permissions Are Used Assembly Invokes a method Required Permissions Permissions Granted Exception! Allowed!

9 Quick.NET Framework Refresh Assemblies Assemblies Logical collection of one or more EXE or DLL files containing code & resources Logical collection of one or more EXE or DLL files containing code & resources Can be a single file (EXE or DLL) Can be a single file (EXE or DLL) Can be a logical (not physcial) collection of more than one file residing in the same directory Can be a logical (not physcial) collection of more than one file residing in the same directory Stored in either the Global Assembly Cache, or the local app directory Stored in either the Global Assembly Cache, or the local app directory

10 Identifying Assemblies – Stong Names An assembly contains a manifest An assembly contains a manifest Describes global attributes and layout Describes global attributes and layout Publisher, assembly name, version, … Publisher, assembly name, version, … Contains the public key of the signer Contains the public key of the signer A strong named assembly is signed A strong named assembly is signed Signatures don’t use a third party Signatures don’t use a third party No automatic means to associate signature key with the publisher No automatic means to associate signature key with the publisher No revocation mechanism No revocation mechanism

11 Uses of Strong Names Only strong named assemblies can be loaded into the global catalogue Only strong named assemblies can be loaded into the global catalogue Strong names allow multiple versions of an assembly to co-exist Strong names allow multiple versions of an assembly to co-exist No “DLL Hell” No “DLL Hell” Protects against tampering Protects against tampering Permissions can be assigned to strong names Permissions can be assigned to strong names Useful for interface and inheritance restrictions Useful for interface and inheritance restrictions Required to allow partially trusted callers Required to allow partially trusted callers

12 Application Domains Operating System Job Object Process Native Execution.NET Framework App Domain Assembly Managed Code

13 Application Domains App domains contain one or more assemblies App domains contain one or more assemblies App domain created by a host App domain created by a host If a specific app domain isn’t created, assemblies get loaded into the default domain If a specific app domain isn’t created, assemblies get loaded into the default domain Useful when you want to provide fewer rights than provided by default policy Useful when you want to provide fewer rights than provided by default policy Browser Host Browser Host Custom Host Custom Host Server Host (ASP.NET) Server Host (ASP.NET) Also used when loading an assembly you’d like to unload later Also used when loading an assembly you’d like to unload later

14 Evidence Evidence applies to the code, not the user running the code Evidence applies to the code, not the user running the code Applied to an assembly or app domain Applied to an assembly or app domain Two types of evidence Two types of evidence Host-provided evidence Host-provided evidence Assembly-provided evidence Assembly-provided evidence Evidence changes when code is run from different places! Evidence changes when code is run from different places!

15 Host-Provided Evidence Application Directory Application Directory Directory the code is running from Directory the code is running from Hash Hash Typically a SHA1 or MD5 hash of the assembly Typically a SHA1 or MD5 hash of the assembly PermissionRequestEvidence PermissionRequestEvidence Permissions requested by the assembly Permissions requested by the assembly Only visible during policy resolution Only visible during policy resolution Publisher Publisher Authenticode signature Authenticode signature

16 Host-Provided Evidence (2) Site Site Web site of origin Web site of origin StrongName StrongName A cryptographically strong binding of a name, version and culture A cryptographically strong binding of a name, version and culture URL URL URl of origin URl of origin Zone Zone IE security zone for the assembly IE security zone for the assembly

17 Evidence Example Host Evidence: file://C:/projects/CSharpCruft/bin/Release/CSharpCruft.exe MyComputer Host Evidence: file://BYTEME/C$/projects/CSharpCruft/bin/Release/CSharpCruft.exe Intranet Local: From a share:

18 Assembly-Provided Evidence Allows an assembly to provide custom evidence Allows an assembly to provide custom evidence Cannot override any default host-provided evidence Cannot override any default host-provided evidence If host evidence is included in an assembly it is ignored by the.NET runtime If host evidence is included in an assembly it is ignored by the.NET runtime Can be any type of data, from a simple integer to a signed XML statement Can be any type of data, from a simple integer to a signed XML statement

19 Assigning Privileges Security Policy maps code identity to privileges Security Policy maps code identity to privileges Evidence defines identity Evidence defines identity Membership Conditions Membership Conditions Represented by extensible objects Represented by extensible objects Determines membership given evidence as input Determines membership given evidence as input Code Groups Code Groups Hierarchal mapping between policy and membership conditions Hierarchal mapping between policy and membership conditions Policy Levels Policy Levels Contains a permission set, code group and “full trust” assembly list Contains a permission set, code group and “full trust” assembly list

20 Policy – Membership Conditions Determines whether an assembly is a member of a group based on evidence Determines whether an assembly is a member of a group based on evidence Implements IMembershipCondition Implements IMembershipCondition Can be customized – useful with custom evidence classes Can be customized – useful with custom evidence classes Default membership condition classes Default membership condition classes HashMembershipCondition HashMembershipCondition SiteMembershipCondition SiteMembershipCondition ZoneMembershipCondition ZoneMembershipCondition Etc, etc. Etc, etc.

21 Policy – Code Groups Constructed from a membership condition and a PolicyStatement Constructed from a membership condition and a PolicyStatement PolicyStatement contains: PolicyStatement contains: PermissionSet PermissionSet Attributes Attributes Exclusive – any assembly matching membership condition receives permissions only from this code group Exclusive – any assembly matching membership condition receives permissions only from this code group LevelFinal – No lower level groups are evaluated LevelFinal – No lower level groups are evaluated All – Exclusive and LevelFinal All – Exclusive and LevelFinal Nothing – not Exclusive or LevelFinal Nothing – not Exclusive or LevelFinal

22 Policy – Policy Levels Four Policy Levels exist: Four Policy Levels exist: Enterprise Enterprise Machine Machine User User App Domain App Domain Resulting permissions are the intersection of the permissions from all policies Resulting permissions are the intersection of the permissions from all policies Allows lower levels to set policies more restrictive than upper levels Allows lower levels to set policies more restrictive than upper levels Unless LevelFinal attribute encountered Unless LevelFinal attribute encountered

23 Resolving Permissions For each Policy Level For each Policy Level Membership conditions are resolved Membership conditions are resolved Permission set is intersection of permissions for code groups for the assembly Permission set is intersection of permissions for code groups for the assembly If LevelFinal is encountered, lower levels are not evaluated If LevelFinal is encountered, lower levels are not evaluated Each lower level can reduce permissions Each lower level can reduce permissions Lower levels cannot increase permissions Lower levels cannot increase permissions

24 Permissions Types of Permissions: Types of Permissions: Code Access Permissions Code Access Permissions Standard permissions derived from System.Security.CodeAccessPermission Standard permissions derived from System.Security.CodeAccessPermission Identity Permissions Identity Permissions Represents evidence Represents evidence Zone evidence creates a ZoneIdentityPermission Zone evidence creates a ZoneIdentityPermission Custom Permissions Custom Permissions Could be App Domain specific Could be App Domain specific

25 Using Permissions Granted by security policy Granted by security policy Policy states that any assembly that provides certain evidence is allowed specific permissions Policy states that any assembly that provides certain evidence is allowed specific permissions Permission demands Permission demands Used by trusted code to require permissions of semi-trusted callers Used by trusted code to require permissions of semi-trusted callers

26 Stating Permission Requirements Declarative Declarative Stored in an assembly’s metadata Stored in an assembly’s metadata Available at load time Available at load time Can be placed at class or method level Can be placed at class or method level Easily reviewed by a host Easily reviewed by a host Imperative Imperative Requires permissions at run-time Requires permissions at run-time Allows more complex logic Allows more complex logic Permission Sets Permission Sets Any operation that can be performed on a single privilege can be performed on a set Any operation that can be performed on a single privilege can be performed on a set Increases performance Increases performance

27 Walking the Stack A Stack Walk is triggered when a permission is required to continue A Stack Walk is triggered when a permission is required to continue Designed to overcome luring attacks Designed to overcome luring attacks Ensures that the original caller has enough permissions to perform an action Ensures that the original caller has enough permissions to perform an action

28 Asserting Permissions Assert stops the stack walk in your code for the permission asserted Assert stops the stack walk in your code for the permission asserted No effect on other permissions No effect on other permissions Must be used with care Must be used with care Claims that you can allow semi-trusted callers to perform higher-level actions safely Claims that you can allow semi-trusted callers to perform higher-level actions safely

29 Denying Permissions Deny also stops the stack walk immediately Deny also stops the stack walk immediately Throws a security exception when encountered Throws a security exception when encountered Rarely useful in practice, except in testing Rarely useful in practice, except in testing When creating custom permissions be sure and test negative case When creating custom permissions be sure and test negative case PermitOnly PermitOnly Allows request only if the requested set of permissions is a subset of the allowed set Allows request only if the requested set of permissions is a subset of the allowed set Can be useful in hosting applications and testing Can be useful in hosting applications and testing

30 Class and Method Permissions LinkDemand – used to restrict the callers of public methods LinkDemand – used to restrict the callers of public methods InheritanceDemand – used to restrict which code can inherit from your assembly InheritanceDemand – used to restrict which code can inherit from your assembly

31 Design Scenarios Security-neutral code Security-neutral code Does nothing with the security subsystem Does nothing with the security subsystem Must typically be installed locally Must typically be installed locally Few advantages over native code Few advantages over native code Non-reusable application Non-reusable application Should take steps to ensure semi-trusted callers are blocked Should take steps to ensure semi-trusted callers are blocked Managed wrapper over native code Managed wrapper over native code Needs to be carefully validated Needs to be carefully validated Similar problem to an ActiveX control Similar problem to an ActiveX control Library code that exposes protected resources Library code that exposes protected resources Must take care to demand appropriate permissions Must take care to demand appropriate permissions Code and design must be carefully evaluated Code and design must be carefully evaluated

32 Development Considerations Principle of Least Privilege Principle of Least Privilege Ask for the permissions your assembly requires Ask for the permissions your assembly requires Explicitly refuse all other permissions Explicitly refuse all other permissions Protects you from coding and design errors by limiting your assembly Protects you from coding and design errors by limiting your assembly Read The Fine Manual! Read The Fine Manual! Read “Secure Coding Guidelines” in.NET Framework SDK Read “Secure Coding Guidelines” in.NET Framework SDK User input is just as evil as it was with native code! User input is just as evil as it was with native code!

33 Securing Methods If another assembly calls into your object, the methods it calls must be public If another assembly calls into your object, the methods it calls must be public Not all public methods need to be available to all users Not all public methods need to be available to all users Similar problem to undocumented DLL exports Similar problem to undocumented DLL exports Solutions Solutions Limit scope of methods when possible Limit scope of methods when possible Require callers to have a specific identity Require callers to have a specific identity Use inheritance demands to limit sub-classes Use inheritance demands to limit sub-classes Can be used to restrict which methods can be overridden Can be used to restrict which methods can be overridden

34 Tricks and Traps LinkDemand LinkDemand Only checks the immediate caller during JIT Only checks the immediate caller during JIT If a LinkDemand is required on a derived method, it must also be required on the base method If a LinkDemand is required on a derived method, it must also be required on the base method Assembly.Load Assembly.Load Loads an assembly using the evidence of the caller, NOT the assembly being loaded Loads an assembly using the evidence of the caller, NOT the assembly being loaded

35 Conclusions Managed code is a great tool Managed code is a great tool Like all tools, you have to understand how they work Like all tools, you have to understand how they work Managed code is NOT a silver bullet Managed code is NOT a silver bullet It is possible to create security holes in any language It is possible to create security holes in any language.NET Security adds complexity.NET Security adds complexity Differences in execution context can create large differences in how your code runs Differences in execution context can create large differences in how your code runs

36 Additional Resources.NET Framework Security.NET Framework Security LaMacchia, Lange, Lyons, Martin and Price LaMacchia, Lange, Lyons, Martin and Price.NET Framework SDK.NET Framework SDK Secure Coding Guidelines Secure Coding Guidelines Writing Secure Code, 2 nd Edition Writing Secure Code, 2 nd Edition

37 © 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.


Download ppt "Understanding.NET Framework Security David LeBlanc Microsoft Office."

Similar presentations


Ads by Google