Dotnet course 12 ppsx

Microsoft.NET Architecture and the C# Language A semester course for 4 th year students Comments to the presentations Prof. Vladimir O. Safonov, St. Petersburg University Email: v_o_safonov@mail.ru WWW: http://user.rol.ru/~vsafonov Lecture 12. Slide 2. This lecture is devoted to .NET security – the most flexible security systems of all currently known software development platforms. Slide 3. The plan and goals of this lecture are as follows: .NET Framework security system Role-Based Security Code Access Security Security Policy Slide 4. This picture demonstrates one of the most widespread examples of security issues experienced by millions of users all over the world – viruses spreading by email. One should be very careful when opening an email or moreover its attachments when the sender address is unfamiliar: there is a big risk to infect the computer with a virus. Slide 5. Sources of the security problems are well known. The first group of sources is related to lack of code execution management . Any bug in the code can potentially be used as a basis for security attack. The most well known example is buffer overflow attack . In addition, using third-party components may also cause security issues, since the code to be used is not known to the user and probably not reliable and not well tested. Sure in a managed code execution environment, with more type and security checking, all or most of the problems mentioned would be detected and resolved very quickly. Another group of sources is related to mobile code and data - email attachments , macros in documents, and in general any information traveling over the Internet and downloaded by its users. All of the above can potentially be a source of virus or worm infection and cause destructions of a computer system because of some malicious application or hacker. Slide 6. An earlier approach to security is demonstrated by Java. Java security is based on two major ideas: - there should be a SecurityManager class that should be defined by any browser; - any applet downloaded to a client host from the network should not be allowed almost anything to do – no local files inspection of updating, no network connections, etc., except for using the information from the same server the applet was downloaded. The former model is not flexible enough. The latter one, referred to as sandbox model, is too restrictive because it actually does not allow corporate distributed applications to run. In addition, Java security is only applicable to Java . Slide 7. NET Framework offers the following principles for solving security problems. The first principle is the managed code execution provided by CLR. Runtime type checking and security checking enables a good basis to make the code more secure. The second principle is the security model oriented to checking permissions of the code. In a lot of earlier systems like UNIX security is based on the concepts of user and group. Tying security information to the code (assembly) in the form of special attributes and configuration files is more reliable because it enables a proper security mode and permissions for using any assembly traveling across the network in any environment. The third principle is to use security policies as combinations of security related information resulting from the evidences of the assembly, the host configuration, the developer information, and so on. Such approach gives much more flexibility than earlier approaches taken on traditional systems. The fourth principle is to provide a variety of features for customizing security system: - attributes, configuration files, security demand requests from the code, descriptions of users and their roles in the system, and so on. Slide 8. The contents of the lecture is the following: - General definitions - Kinds of permissions - Using roles - Code access security - Security policies - Customizing the security system Slide 9. Role-based security is aimed at taking into account the users and their roles. Its basic notions are as follows. Identity is a user or an entity acting on her behalf. Principal is an identity with her security context (a set of her roles). The roles are denoted by strings and can be, for example, “administrator”, “manager”, or any others, as defined in the application. There are three kinds of principals in .NET Framework. Generic principal is a principal whose authorization scheme does not depend on the operating system (Windows 2000/XP/2003) domain. In creating a generic principal, its set of roles is indicated as an array of strings. Windows principal is a principal whose identity is validated by the Windows domain. Custom principal is a principal whose class is defined by the user, based on the IPrincipal interface. Slide 10. Authentication is the procedure of identifying and checking the principal’s identity. There can be various authentication models – Basic, Digest, Passport, Integrated (based on NT LAN Manager, or NTLM, or on Kerberos v5). Generally speaking, in an integrated corporate solution user authentication can take a variety of forms – from passwords and certificates, up to smart cards and biometrics. Authorization is the procedure of checking the principal’s permissions to perform an operation (or to get access to a secured resource). Slide 11. Permissions are the result of authorization of a principal. Permissions can be requested by an assembly by placing a set of security attributes into the code. The final decision to grant the permissions is made by the CLR at runtime, based on the assembly’s requests and the security policy. During execution, a given security permissions can be demanded by calling the Demand method in an assembly from the appropriate security permissions object. The requested or demanded permissions for an assembly can be denied by the CLR if they don’t comply to the security policy. Slide 12. Following our agenda, now let’s proceed with kinds of permissions. Slide 13. There can be three kinds of permissions – code access permissions, identity permissions and principal permissions. Code access permission is a code permission to access a secured resource or to perform a secured operation. Examples of those are EnvironmentPermission, FileDialogPermission, FileIOPermission, ReflectionPermission. They are related to read local environment variables, to read or update local files, and to perform reflection on assemblies available on the local machine. Identity permissions represent sets of permissions that belong to the identities defining the origin of the assembly. PublisherIdentityPermission, SiteIdentityPermission, StrongNameIdentityPermission, ZoneIdentityPermission, URLIdentityPermission refer to the identity permissions for the publisher of the code, the zone, site and URL from which the code originates, and identity permissions for strong names. Role-based security permissions define the set of permissions related to the principal’s belonging to some role. PrincipalPermission is a class to make security checks against the current active principal. User can also define her own kinds of permissions. Slide 14. The IPermission interface is the common base for all mentioned permission classes. In contains a number of operations on permissions in set-theoretic style: - Copy() - creates a duplicate of the current permission object; - Intersect() - creates a set-theoretic intersection of two sets of permissions; - Union() – creates a set-theoretic union of two sets of permissions; - IsSubsetOf() – checks whether a given set of permissions is a subset of another set of permissions. In addition, this interface provides a basic operation for checking permissions: Demand() checks if the current principal has a given set of permissions. If not, a SecurityException is thrown. Slide 15. .NET security system provides permissions for managing permissions. SecurityPermissionAttribute is the class to define the related attribute. It has a number of properties that define a variety of kinds of permissions: - AllFlags – unrestricted permission to control the permissions; - UnmanagedCode – permission to execute unmanaged code; - ControlAppDomain – permission to control the application domain; - Assertion – permission to guarantee permissions, a nd many others. Slide 16. The example given on this slide demonstrates how to check security permissions. The permissions in this example are checked by calling the Demand method. In this example, a permissions object is created to describe security permissions for possible actions on a given file. Please note that the Demand method throws a SecurityException if the required permission is not granted to the assembly. Slide 17. The example shown on the slide demonstrates another way of checking security permissions. The permissions are defined as attributes, are part of metadata and are checked automatically. Slide 18. The previous example shown the way for declarative security permissions checks Advantages of this approach are: simplicity and availability for reflection. In particular, this method can be used by system tools for detecting conflicts. The shortcoming of this approach is no opportunity to process exception s. Slide 19. Now let’s proceed with using roles of principals. Slide 20. Roles of principals are used for access separation for user groups. The role of a principal can be checked by the IsInRole method as shown. Using the result of authentication can be performed by properties of the IIdentity interface: Name shows the name of the identity; IsAutenticated indicates that the identity has been authenticated, and AuthenticationType shows the type of authentication of the identity. The PrincipalPermission class can be used to create an identity with a given name and role. Slide 21. It is possible either to learn or to replace the current principal. It is attached to the current thread and is referred to by the CurrentPrincipal property of the Thread class. An opportunity to substitute the current principal is helpful in case one’s own authentication mechanism is used. And it is absolutely necessary in case of working on behalf of some other user . Rights to substitute the principal are controlled by the SecurityPermission class. In more detail, the SecurityPermissionFlag.ControlPrincipal value denotes an appropriate permission. If it is violated, a SecurityException is thrown. Slide 22. It is possible to use the WindowsPrincipal class to check the Windows group membership of a Windows user. Setting the kind of a principal to be a WindowsPrincipal and getting the current (Windows) principal is performed as shown on the slide. Slide 23. For Windows principals, it is possible to impersonate the user. Impersonation is actually a kind of temporary changing the user, with an opportunity to undo this action, as shown on the slide. Using system calls it is possible to get the user’s token, then make the impersonation by creating a new Windows identity. On finishing work it is possible to return to the current principal by calling the Undo method from the Windows impersonation context. Please note that this feature is available on Windows XP and Windows 2003 only. Slide 24. Now according to our plan let’s proceed with Code Access Security. Slide 25. Code access security is a limitation of access to resources for a given code (assembly). Security permissions for the code depend on the machine. On different machines they can be different. So the code can never get arbitrary permissions, and the author of the code can never be sure that the code will be allowed to execute and perform the actions it claims to do. Security checks are first made by the verifier when the code is loaded into the CLR host. The verifier checks that the CIL code is type safe, that is, each type is used properly, each operation on the object complies to its type, and each identifier is what is declared and intended to be. These checks guarantee that the code is secure in the sense that it cannot make an attempt to access to a memory area it shouldn’t have access to or to perform an illegal operation. Another part of security checks is performed by the CLR when calling a method. Permissions are checked for the whole calling stack (the sequence of the methods called, or dynamic chain). So if a method is not allowed to execute within some calling sequence of other methods, it will not be allowed to execute by the CLR, and a SecurityException will be generated. So, there is no chance for a code to hide real permissions, and the resulting set of permissions is granted to a code according to the principle of minimal permissions . Slide 26. The scheme on the slide illustrates the process of security stack walk. It is performed by the CLR to check the permissions of the method being called, alongside with the permissions of all other methods in the calling sequence. The set of permissions P requested by the method from the assembly A4 is compared in turn to the rights of each assembly whose method is called on the stack. If it fails to compare for any of the assemblies, a security exception is generated. Such technique in particular is used by the CLR each time an unmanaged code is called from managed code. Slide 27. During the stack walk some assemblies play the part of stack modifiers. They control the current state of the process of checking and assigning rights during the stack walk. An example of stack modifier is a managed wrapper for unmanaged resource. It requires appropriate permissions from the callers, guarantee the security of calling unmanaged code, and performs the call of unmanaged code if allowed. Slide 28. The IStackWalk interface is a set of methods to be performed during the stack walk. All of them are called from the current security object that describes some set of permissions to be granted. Demand - determines at runtime whether all callers have been granted the permissions specified by the current permission object. Assert - switches off the security checks for all the callers. That is, by calling this method the code express its trust to those who called it. Deny – switches off any permissions requested by any Demand method called from the code for the current object. So, this is a volunteer action to restrict permissions of the code. Each Demand method called from the code afterwards for the current object will fail. PermitOnly - - switches off, for all the callers, the permissions to access other resources but the current one, even they had such permissions. So, actually, this method is called to permit only access to the current resource. In addition, the CodeAccessPermission class that implements the IStackWalk interface also has static methods to cancel any stack modifier: RevertAll deletes all previously set Assert, Deny or PermitOnly stack modifiers from the frame. There are also static methods to delete separately each of the three listed modifiers. Slide 29. To create one’s own permissions for checking code, one should define a class derived from the CodeAccessPermission abstract class. In particular, there are a number of predefined classes alreadt derived from that class, in particular: - DBDataPermission – represents access to a database; - IsolatedStoragePermission – represents access to isolated data storage; - ResourcePermissionBase – represents access from code to system resources. Slide 30. According to our plan, now let’s consider security policies. Slide 31. There are three major parts of .NET security mechanisms: - Permissions, considered before, are represented by authorization objects and operations on them; - Policy defines the set of permissions granted to an assembly; - Evidence is information about the assembly from different sources collected by the CLR - the author, the developer company, etc., for assigning the set of permissions to the assembly. All three kinds of security related information are fully extensible . Slide 32. Evidence on the assembly is the input data for the policy. From programmatic viewpoint, evidence information is represented as the Evidence property of the Assembly class. To gather evidence information on an assembly, the following items are taken into account: - From which site has the assembly been downloaded; - To which zone does the assembly belong; - What is the strong name of the assembly; - Who signed the assembly. Evidences are fully extensible. Evidence will be taken into account only if there is any interest in it Slide 33. Security policy is the process of determining the permissions. In .NET, unlike all the earlier systems, security is assigned to a code rather than to a user. There is a separate permission set for each assembly. The steps to be performed by the CLR to ensure .NET security model are as follows: - Collect the evidences on the assembly (as explained before); - Present the evidences to the security policy and get the set of permissions from it; - Clarify the resulting permission set, based on extra requirements by the assembly; - Assign to the assembly the final set of permissions. Slide 34. There are three security layers in .NET: - Security permissions applicable to all computers on the (enterprise) network; - Security permissions applicable to a single computer; - User specific security permissions. All in all, these sets of security permissions can intersect as shown on the scheme. Further security restrictions are possible at the level of application domain. Slide 35. A security layer consists of code groups, as shown on the slide. Permissions are associated to code groups. P1 (all the code, the root of the graph) == Nothing. Evidences determine belonging to a group. Position in the hierarchy is taken into account. Slide 36. Named permission set is an alternative to attach a security permission attribute to an assembly. Names are related to the attribute objects of the PermissionSetAtribute, with a Name value representing the name of the desired permission set. Nothing means the code has no permissions, so it cannot be executed. Execution means that the code has no access to secured resources but can be executed. The other names of permission sets are: Internet, LocalIntranet, Everything, SkipVerification and FullTrust. The latter one means access to all system resources. Slide 37. Assemblies can request permissions using attributes. The following three kinds of requests applicable to assemblies only: SecurityAction.RequestMinimum – means that the requested permission is necessary for the assembly to run. SecurityAction.RequestOptional – means that the requested permission is optional for the assembly, i.e. it will still be running even without getting this permission. SecurityAction.RequestRefuse – means that this permission is undesirable for this assembly, and it will deny it when executing. If a policy is assigned a set narrower than “Minimum”, then the assembly is not loaded at all. [...]... security; - Security policies; - Customizing the security system Slide 42 This slide presents some useful references, including Web sites and books related to NET security Slide 43 As the home task to lecture 12, we offer you to compare NET security to Java security . course for 4 th year students Comments to the presentations Prof. Vladimir O. Safonov, St. Petersburg University Email: v_o_safonov@mail.ru WWW: http://user.rol.ru/~vsafonov Lecture 12. Slide. permissions for an assembly can be denied by the CLR if they don’t comply to the security policy. Slide 12. Following our agenda, now let’s proceed with kinds of permissions. Slide 13. There can be three. including Web sites and books related to .NET security. Slide 43. As the home task to lecture 12, we offer you to compare .NET security to Java security.