380 likes | 574 Views
Understanding .NET Framework Security. David LeBlanc Microsoft Office. Agenda. .NET Framework Security Fundamentals Evidence Permissions Policy .NET Framework security administration Needed for setup When to use .NET Framework vs. core OS security. Why Is This Important?.
E N D
Understanding .NET Framework Security David LeBlancMicrosoft Office
Agenda • .NET Framework Security Fundamentals • Evidence • Permissions • Policy • .NET Framework security administration • Needed for setup • When to use .NET Framework vs. core OS security
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 • Code running locally isn’t the same as code running from a share
What .NET Is and Isn’t • .NET IS a great new toolset • Can be used to solve previously unmanageable security problems • Largely eliminates buffer overruns • Allows a system or host application to restrict the capabilities of managed code
.NET IS NOT a Silver Bullet • A majority of security mistakes are language-independent • Bad design is still bad design • New capabilities provided by .NET can be misused • New, improved ways to make security mistakes! • Code running as fully trusted is just as dangerous as a native binary!
User and Code Identity Security • Classic OS security is based on limiting the capabilities of a user or group • Still an effective mechanism • Does not help when code is either untrusted or semi-trusted • Code Identity Security • 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
Permissions Assembly HostingApp Domain Evidence Policy How Permissions Are Resolved
PermissionsGranted Assembly RequiredPermissions Invokes a method Exception! Allowed! How Permissions Are Used
Quick .NET Framework Refresh • Assemblies • Logicalcollection of one or more EXE or DLL files containing code & resources • 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 • Stored in either the Global Assembly Cache, or the local app directory
Identifying Assemblies – Stong Names • An assembly contains a manifest • Describes global attributes and layout • Publisher, assembly name, version, … • Contains the public key of the signer • A strong named assembly is signed • Signatures don’t use a third party • No automatic means to associate signature key with the publisher • No revocation mechanism
Uses of Strong Names • Only strong named assemblies can be loaded into the global catalogue • Strong names allow multiple versions of an assembly to co-exist • No “DLL Hell” • Protects against tampering • Permissions can be assigned to strong names • Useful for interface and inheritance restrictions • Required to allow partially trusted callers
Operating System .NET Framework Job Object App Domain Process Assembly Assembly Application Domains Native Execution Managed Code
Application Domains • App domains contain one or more assemblies • App domain created by a host • 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 • Browser Host • Custom Host • Server Host (ASP.NET) • Also used when loading an assembly you’d like to unload later
Evidence • Evidence applies to the code, not the user running the code • Applied to an assembly or app domain • Two types of evidence • Host-provided evidence • Assembly-provided evidence • Evidence changes when code is run from different places!
Host-Provided Evidence • Application Directory • Directory the code is running from • Hash • Typically a SHA1 or MD5 hash of the assembly • PermissionRequestEvidence • Permissions requested by the assembly • Only visible during policy resolution • Publisher • Authenticode signature
Host-Provided Evidence (2) • Site • Web site of origin • StrongName • A cryptographically strong binding of a name, version and culture • URL • URl of origin • Zone • IE security zone for the assembly
Evidence Example Local: Host Evidence: <Url>file://C:/projects/CSharpCruft/bin/Release/CSharpCruft.exe</Url> <Zone>MyComputer</Zone> From a share: Host Evidence: <Url>file://BYTEME/C$/projects/CSharpCruft/bin/Release/CSharpCruft.exe <Zone>Intranet</Zone>
Assembly-Provided Evidence • Allows an assembly to provide custom evidence • Cannot override any default host-provided evidence • 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
Assigning Privileges • Security Policy maps code identity to privileges • Evidence defines identity • Membership Conditions • Represented by extensible objects • Determines membership given evidence as input • Code Groups • Hierarchal mapping between policy and membership conditions • Policy Levels • Contains a permission set, code group and “full trust” assembly list
Policy – Membership Conditions • Determines whether an assembly is a member of a group based on evidence • Implements IMembershipCondition • Can be customized – useful with custom evidence classes • Default membership condition classes • HashMembershipCondition • SiteMembershipCondition • ZoneMembershipCondition • Etc, etc.
Policy – Code Groups • Constructed from a membership condition and a PolicyStatement • PolicyStatement contains: • PermissionSet • Attributes • Exclusive – any assembly matching membership condition receives permissions only from this code group • LevelFinal – No lower level groups are evaluated • All – Exclusive and LevelFinal • Nothing – not Exclusive or LevelFinal
Policy – Policy Levels • Four Policy Levels exist: • Enterprise • Machine • User • App Domain • Resulting permissions are the intersection of the permissions from all policies • Allows lower levels to set policies more restrictive than upper levels • Unless LevelFinal attribute encountered
Resolving Permissions • For each Policy Level • Membership conditions are resolved • Permission set is intersection of permissions for code groups for the assembly • If LevelFinal is encountered, lower levels are not evaluated • Each lower level can reduce permissions • Lower levels cannot increase permissions
Permissions • Types of Permissions: • Code Access Permissions • Standard permissions derived from System.Security.CodeAccessPermission • Identity Permissions • Represents evidence • Zone evidence creates a ZoneIdentityPermission • Custom Permissions • Could be App Domain specific
Using Permissions • Granted by security policy • Policy states that any assembly that provides certain evidence is allowed specific permissions • Permission demands • Used by trusted code to require permissions of semi-trusted callers
Stating Permission Requirements • Declarative • Stored in an assembly’s metadata • Available at load time • Can be placed at class or method level • Easily reviewed by a host • Imperative • Requires permissions at run-time • Allows more complex logic • Permission Sets • Any operation that can be performed on a single privilege can be performed on a set • Increases performance
Walking the Stack • A Stack Walk is triggered when a permission is required to continue • Designed to overcome luring attacks • Ensures that the original caller has enough permissions to perform an action
Asserting Permissions • Assert stops the stack walk in your code for the permission asserted • No effect on other permissions • Must be used with care • Claims that you can allow semi-trusted callers to perform higher-level actions safely
Denying Permissions • Deny also stops the stack walk immediately • Throws a security exception when encountered • Rarely useful in practice, except in testing • When creating custom permissions be sure and test negative case • PermitOnly • Allows request only if the requested set of permissions is a subset of the allowed set • Can be useful in hosting applications and testing
Class and Method Permissions • LinkDemand – used to restrict the callers of public methods • InheritanceDemand – used to restrict which code can inherit from your assembly
Design Scenarios • Security-neutral code • Does nothing with the security subsystem • Must typically be installed locally • Few advantages over native code • Non-reusable application • Should take steps to ensure semi-trusted callers are blocked • Managed wrapper over native code • Needs to be carefully validated • Similar problem to an ActiveX control • Library code that exposes protected resources • Must take care to demand appropriate permissions • Code and design must be carefully evaluated
Development Considerations • Principle of Least Privilege • Ask for the permissions your assembly requires • Explicitly refuse all other permissions • Protects you from coding and design errors by limiting your assembly • Read The Fine Manual! • Read “Secure Coding Guidelines” in .NET Framework SDK • User input is just as evil as it was with native code!
Securing Methods • 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 • Similar problem to undocumented DLL exports • Solutions • Limit scope of methods when possible • Require callers to have a specific identity • Use inheritance demands to limit sub-classes • Can be used to restrict which methods can be overridden
Tricks and Traps • LinkDemand • 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 • Assembly.Load • Loads an assembly using the evidence of the caller, NOT the assembly being loaded
Conclusions • Managed code is a great tool • Like all tools, you have to understand how they work • Managed code is NOT a silver bullet • It is possible to create security holes in any language • .NET Security adds complexity • Differences in execution context can create large differences in how your code runs
Additional Resources • .NET Framework Security • LaMacchia, Lange, Lyons, Martin and Price • .NET Framework SDK • Secure Coding Guidelines • Writing Secure Code, 2nd Edition
© 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.