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/25/04 

Date: Wed, 25 Feb 2004 19:53:47 GMT

Hi Tim,

        I assume you found all the standard MSDN links already, but I'll post them here anyway, just to be complete:

* An Overview of Security in the .NET Framework: http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnnetsec/html/netframesecover.asp

* Security in .NET: The Security Infrastructure of the CLR Provides Evidence, Policy, Permissions, and Enforcement Services
: http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/02/09/SecurityinNET/TOC.ASP

* .NET Framework Developer's Guide to CAS: http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconcodeaccesssecurity.asp

* .NET Framework Developer's Guide to Role Based Security:http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconrole-basedsecurity.asp

         I'll try to address all of your questions here. You are correct in that CAS is based upon how much you trust the code rather than how much
you trust the user. However, CAS is built on top of the NT security system, so just having some managed code that has been granted FullTrust
does not automatically mean that a non-administrator will be able to, say, format your hard drive. Role based security is the extension of the NT
security system up into the managed world, and it is a seperate concept from CAS.
        The easiest way to tell if a permission belongs to the CAS system is to check to see if it derives from
System.Security.CodeAccessPermission. All of the standard permissions (FileIO, Registry, Web, etc.) and the *Identity permissions
(StrongNameIdentity, SiteIdentity, etc) derive from this base class, and thus are part of the CAS system. Again, role based security is orthogonal
from CAS. Since role based security is a seperate concept, your statement "Code Access Security is access based on the identity of the code
not the user running it " is 100% correct.
        Identity permissions are assigned based upon the evidence presented to the security system. For instance, if an assembly is signed with
a strong name, demands for the corresponding StrongNameIdentityPermission will pass. One of the more common uses of the identity
permissions is to write code that is only meant to be called by assemblies you write (by placing a LinkDemand for a
StrongNameIdentityPermission on the external interfaces).
        Role based permissions (the PrincipalPermission) allow you to shut down your application to people not in certain Windows roles or
logins. This is more along the lines of a "traditional" security model. However, if you don't care about exact roles or users using your application,
then you don't ever need to use role based security. Again, CAS is built on top of Windows NT security, so you don't have to ensure that whoever
is running your application actually has the Windows NT rights to do something, the Windows kernel will do that for you.

        Although it's not a term that's in common use, Evidence-Based security would be just another name for standard CAS, where an assembly
is granted permission based upon how much you trust it, rather than how much you trust the user running it.

        Imperative and declarative security are ways of making sure that every assembly in the call stack has a specific permission or set of
permissions. In your example, when you try to write a file on the C drive, the System.IO classes will have either a declarative or imperative
demand (in this case an imperative demand for the file you're trying to write) for FileIOPermission. The CAS system will walk the callstack and
check every stack frame for this FileIOPermission. (This is a simplified explanation ... things like Asserts can cause different behavior, but in the
general case, this is what happens.) If every stack frame has this permission, the file will be opened. Otherwise, you will get a SecurityException.
        For instance, if you write an assembly that writes a file to c:\. This assembly is fully trusted and runs under a fully trusted application, then
you will be able to write the file without a problem. However, if someone writes a control and hosts it on their web page, and calls into your
assembly, a SecurityException will be thrown. (under the default policy).
        To accomplish what you want to do in your example, you don't use imperative or declarative security (like I said, the security demand is
actually done for you in the BCL), instead you modify the security policy creating a chain of code groups that check for each of your conditions. At
the end of that chain, you'd allow FileIOPermission to the C drive. In every other permission set, you would not allow FileIOPermission to the C
drive.

        I've tried to clarify some of your points of confusion, if you have any other questions, feel free to post a reply, and I'd be glad to clear it up
some more.

-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: AcP7KWJUmGNqrRlrSJC34Ap7+/11aQ==
>X-Tomcat-NG: microsoft.public.dotnet.security
>From: =?Utf-8?B?Tm92aWNl?= <6tc1ATqlinkDOTqueensuDOTca>
>Subject: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?
>Date: Tue, 24 Feb 2004 14:56:05 -0800
>Lines: 43
>Message-ID: <9384B26B-312C-4321-A85F-34FDB069BC86@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
>NNTP-Posting-Host: tk2msftcmty1.phx.gbl 10.40.1.180
>Path: cpmsftngxa06.phx.gbl!cpmsftngxa10.phx.gbl
>Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5119
>X-Tomcat-NG: microsoft.public.dotnet.security
>
>Sorry to repost, I'm in somewhat of a desperate situation and I have found that often people will be less inclined to try to assist on a posting if it 
already has a reply and/or the post is asking a lot of questions.  In my previous post someone just posted an agreement comment - as opposed 
to answers to my questions.  Anyway, in the hopes of making the response to my post less onerous - I will just ask one of my questions:
Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?
And then if you are feeling ambitious, please feel free to tackle some of the other questions in my original post (see below).
---------------------------------------------------
Hi, I've done some reading on Microsoft .NET security and am a little confused on the relationship between Code Access Security, Evidence 
Based Security, Code Access Permission, Role Based Permission, Declarative and Imperative Security Statements, etc.
Here is my current understanding:
Code Access Security is access based on the identity of the code not the user running it (if this is true, then only the Identity Permission Code 
Access Permission should fall under CAS - i.e. role-based security shouldn't be a part of CAS).  Protected operations in CAS are file I/O, access to 
the registry, etc.  CAS is being used when an assembly's evidence is examined and a set of configurable rules (security policy) are applied to 
determine a code's permissions.
There are three types of "permission classes" (I'm quoting "permission classes" because of confusion of the word permission in both Identity 
Permission and Role-Based Permission):
Identity Permission, Code Access Permission and Role Based Permission
Permission objects of the above types are assigned to an assembly based on its evidence and the security policy when the assembly is loaded 
into the CLR.  All three "permission classes" fall within the domain of CAS or do only Code-Access Permissions and Identity Permissions fall within 
the domain of CAS???????  It seems likely to me that since you can enforce CAS using all of the "permission classes" then all three "permission 
classes" fall under the domain of CAS.  However, the statement:
"Code Access Security is access based on the identity of the code not the user running it "
doesn't seem in agreement with that.
-----------------------------
--Identity Permission --
amounts to the values of host evidence associated with an assembly.  To me it makes little sense to call this Identity Permission, since they are 
just values of the evidence of an assembly and regardless of any of the values of the evidence, the permissions granted to an assembly are 
based on the evidence AND the security policy - I could set up my security policy not to give any permissions to evidence of any type.  
--Code-Access Permission-- 
amounts to all the different types of permissions that can be granted to an assembly - file access, network access, etc.  This makes sense, since 
these are actual permissions - rights to do certain things.
--Role-Based Permission--
are the values associated with the user id and their role(s) (i.e. the Principal)????  Again this is confusing, these aren't permissions, these are 
merely values that represent the user whose account is being used to execute the assembly (yes, users can be impersonated and thus be 
executed as if the active user were the one being impersonated, but I'm trying to keep this as simple as possible).
-----------------------------
Evidence-Based security is the security you get from using Identity Permissions????  This is a term that was used in a microsoft document - so I 
didn't just invent it.
-----------------------------
Imperative and Declarative Permission Requests or
Imperative and Declarative Permission Styles or
Imperative and Declarative Security Statements are ways of requesting that the current assembly (its evidence) and/or user and/or granted 
permissions (by CLR - using evidence and security policy) have certain "permissions".  Can Declarative Security Statements make use of all of 
the permission classes?  I.E. can I specify that the access to the C drive is restricted to:
- a particular user or a user belonging to a particular role (i.e. role-based permission)
- an assembly that has access to the entire file system (as granted by the CLR using evidence and security policy)  (i.e. code-access permission)
- an assembly that has an assembly evidence object of type Developer (this would be a customized evidence object) with the name "John Smith" 
(yes I'm aware this is easily falsified)  (i.e. identity-based permission).
-----------------------------
Can someone try to sift through the information I've stated above and confirm/deny the questions and change any inaccuracies.
Thanks,
Novice
>

Relevant Pages