RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?
From: Shawn Farkas (shawnfa_at_online.microsoft.com)
Date: 02/27/04
- Next message: Michel Gallant: "Re: programmatically checking that assembly is authenticode signed?"
- Previous message: konsu: "programmatically checking that assembly is authenticode signed?"
- In reply to: Novice: "RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 27 Feb 2004 02:02:04 GMT
2. They are different types of permissions -- I was just grouping them together to distinguish them from role based security permissions, which
seemed to be your primary source of confusion in the last post.
3. You have this exactly right. You would demand an identity permission in your code if you want to ensure that nobody without that evidence gets
to call you. However, you would use demands of non-identity permissions in your code if you'd like the machine's administrator to decide what
evidence gets to do what. You could almost think of this as an extra level of indirection.
4. You could say that evidence based security is granting, and CAS is the subsystem that does the demanding if that's consistent with the
documentation. I just tend to group the whole system together under the CAS umbrella.
-Shawn
http://blogs.msdn.com/shawnfa
-- This posting is provided "AS IS" with no warranties, and confers no rights. Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated. -------------------- >Thread-Topic: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS? >thread-index: AcP8dS37tF7IB5VYT3+YWqU5scSctg== >X-Tomcat-NG: microsoft.public.dotnet.security >From: =?Utf-8?B?Tm92aWNl?= <6tc1ATqlinkDOTqueensuDOTca> >References: <9384B26B-312C-4321-A85F-34FDB069BC86@microsoft.com> <4KbYYk9#DHA.616@cpmsftngxa06.phx.gbl> <44A3D24D-2E2E- 4B15-919E-299851646FBB@microsoft.com> <O8zih7A$DHA.616@cpmsftngxa06.phx.gbl> >Subject: RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS? >Date: Thu, 26 Feb 2004 06:31:10 -0800 >Lines: 117 >Message-ID: <2A941C7B-9DCA-4F80-8B8C-CE142B598D5F@microsoft.com> >MIME-Version: 1.0 >Content-Type: text/plain; > charset="Utf-8" >Content-Transfer-Encoding: 7bit >X-Newsreader: Microsoft CDO for Windows 2000 >Content-Class: urn:content-classes:message >Importance: normal >Priority: normal >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 >Newsgroups: microsoft.public.dotnet.security >Path: cpmsftngxa06.phx.gbl >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5156 >NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180 >X-Tomcat-NG: microsoft.public.dotnet.security > >Thanks very much for your patience and diligence in answering my questions - hopefully this will be the last round of "clarification" :) 2. In point 2 - you said: "Although there is a distinction between FileIOPermission and StrongNameIdentityPermission, I'm not sure that I would classify them as a code access permission and an identity permission, since StrongNameIdentityPermission is also a code access security permission (ie it derives from CodeAccessPermission)." Most of the publications I have read (Microsoft and others) have said that permissions fall into three categories: Code-Access Permissions Identity Permissions Role-Based Permissions Again, the above is not something I invented (just like I didn't invent the term Evidence-Based Security). O'Reilly makes reference to those Permissions types in Chapter 7. Here is just one of the Microsoft documents I read that also uses the terminology of code access permissions and code identity permissions: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp 3. Ahh, sorry, you're right, I had forgot that imperative and declarative security requests/styles could be used to request Code Identity Permissions - I think I was confused on this point, because I was thinking about the grant set provided through evidence (Identity of the assembly) and the security policy (would you consider the use of evidence and the security policy as being part of Code Identity Permissions - even though those classes aren't explicitly used - I would not, since one is granting and the other is requesting?). For example, I could write an imperative security request that asks for a particular Strong Name (to ensure identity of the assembly). But I could also configure my security policy such that it would grant particular permissions (grant set) based on the Strong Name of the Assembly - however this would be granting rights and the other would just be requesting them. Using the terminology from that MS document - granting permissions through security policy and evidence is evidence based while using declarative and imperative security requests/styles is CAS - though you would say they both belong to CAS. Oh and I think you started to give an example in 3 - "One instance of using a ". 4. I think I agree with your assessment that Evidence Based Security should belong to CAS, but I find the lack of consistency in documentation confusing. Is there another way of differentiating those two types of security (that in your opinion both belong to CAS)? i.e. the one that is associated with granting and the other that is associated with requesting? I'm basically just trying to create a taxonomy for MS .NET Security. 5. O'Reilly says CAS supports the following three permission request operations to address the issues associated with assemblies having too many or too few permissions: Requesting Minimum Permissions Requesting Optional Permissions Refusing Permissions I agree that just because two entities support the same operations/processes does not mean that they belong to the same group. HOWEVER, if it is stated explicitly that entities belonging to a particular group will support certain types of operations, that does imply to me that in order to belong to that group that those entities must support those operations. But you would be correct to say that it is possible for entities outside of that group to also support those operations/processes, since it doesn't say that all entities that support those operations/processes belong to that group - yay logic 101. However, when I first read the above quote from O'Reilly I started to put Role-Based Permissions into the set of CAS, even though O'Reilly had earlier indicated that the two are distinct entities. Thanks, Novice ----- \"Shawn Farkas\" wrote: ----- 1. That is correct -- the inputs to CAS for each assembly are that assembly's evidence and the current security policy. The output is that assembly's grant set. 2. Correct, only permissions which derive from System.Security.CodeAccessPermission are CAS permissions. Role based permissions do not derive from this class. Although there is a distinction between FileIOPermission and StrongNameIdentityPermission, I'm not sure that I would classify them as a code access permission and an identity permission, since StrongNameIdentityPermission is also a code access security permission (ie it derives from CodeAccessPermission). 3. Every permission can restrict access through declarative or imparative demands. One instance of using a It is correct that no request can ever exceed the permissions granted by the operating system. Just because I have a FullTrust assembly doesn't mean that I can read every file on the disk. 4. Identity permissions are a part of CAS. The reason I said that these could be interchangable terms goes back to your first question. Say I have a policy that grants FileIOPermission to the c:\windows directory to any code from Microsoft.com. When I download an assembly from Microsoft.com, the site evidence is evaluated against that policy to produce a permission set containing (at least), a FileIOPermission and a SiteIdentityPermission. The document you read is differentiating between granting permissions and demanding them. I would consider both of these to be part of CAS. 5. Which three operations do O'Reilly define to be required of CAS? Note, that just because an object A supports the operations of object B does not mean that A is a B. For instance, an apple supports being eaten. A potato also supports being eaten. A potato is not an apple however. Since role based security objects do not derive from CodeAccessPermission, they are not CAS permissions. Hopefully that helped to clarify some more of your confusion ... again, if you have more questions, I'd be happy to keep answering :-) -Shawn http://blogs.msdn.com/shawnfa -- This posting is provided "AS IS" with no warranties, and confers no rights. Note: For the benefit of the community-at-large, all responses to this message are best directed to the newsgroup/thread from which they originated. -------------------- >Thread-Topic: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS? >From: =?Utf-8?B?Tm92aWNl?= <6tc1ATqlinkDOTqueensuDOTca>>Subject: RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS? >>Believe it or not, I've actually read a number of technical documents from Microsoft on .NET security - but I do appreciate the additional references. For clarification: 1. Would you consider the Code Access Security policy system to be the system that takes evidence and a security policy (set of configurable rules) as input and produces a set of permissions based on those? The common trend I've seen in Microsoft documents is to compare the above to a function that takes two input variables and gives the output of permissions. 2. a) Instead of saying "Three Permission Classes" I should say there are "Three Types of Permission Classes"? Since there are many permission classes that belong to each of the three types I mentioned (Code Access Permissions, Identity Permissions and Role Based Security Permissions). b) In addition, only Code Access Permissions and Identity Permissions should be thought of as belonging to Code Access Security, correct? However, Role Based Permissions do NOT belong to Code Access Security. 3. a) Through the use of Declarative and Imperative Security requests/statements, ONLY two types of permission classes (role-based permission classes and code access permission classes) can restrict access to protected operations like creating, deleting and modifying files and directories. However, these requests can never allow the user to exceed the permissions that the user has provided to them by the OS (hence the whole idea of .NET being built around the OS - I have a nice diagram that displays this). Is that correct? b) Through the use of Evidence and the configurable security policy Identity Permission classes can be used to restrict access to protected operations like creating, deleting and modifying files and directories. However, these requests can never allow the user to exceed the permissions that the user has provided to them by the OS (hence the whole idea of .NET being built around the OS - I have a nice diagram that displays this). Is that correct? 4. a) You have implied that CAS and Evidence Based Security are different terminology for the same concept - however, wouldn't evidence based security only refer to CAS provided through the use of Identity Permissions? b) Also in one of the Microsoft documents I read***, it differentiated between Evidence-based Security and Code Access Security like this: [snip] which is different from what I would deduce it is from its wording (I stated my deduction in 4.a) ). 5. You have said that Role-Based Permission classes do not belong to Code Access Security - however, in O'Reilly's book Programming .NET Security, page 102 it says "CAS supports the following three permission request operations...." Can you not use these permission requests in conjuncture with Role-Based Permissions? Therefore, wouldn't Role Based Permissions be part of Code Access Security? >
- Next message: Michel Gallant: "Re: programmatically checking that assembly is authenticode signed?"
- Previous message: konsu: "programmatically checking that assembly is authenticode signed?"
- In reply to: Novice: "RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
