Re: Code Access Security, Evidence Based Security, Code Access Permission, Role Based Permission, etc

From: Mary Chipman (mchip_at_nomail.please)
Date: 02/25/04 

Date: Wed, 25 Feb 2004 15:29:48 -0500

Let me try to simplify a bit and explain it in lay(person)s terms :-)

CAS considers the evidence presented by the code at runtime. Usually
(but not always) this evidence consists of where the code originated
(referred to as the zone). It then compares this evidence to security
policy, which is associated with a set of permissions. For example,
code originating from the Internet zone is not allowed File I/O
permissions (among others), and so won't run even if the security
context of the user or process calling the code is a system
administrator. In addition, all callers in the stack have to have
permissions, which prevents untrusted code from calling trusted code.

Now let's say that you have managed code that does have File I/O
permissions, and it passes passes the CAS permissions check. At that
point Windows kicks in and evaluates the security context the code is
running under. If the user/process does not have the appropriate ACLs
set for the file or directory being accessed, then the code won't run
either.

The goal of CAS is to prevent malicious code from executing solely
under the identity of the user or process since most users and many
processes are operating with system administrator privileges. It
doesn't mean that identity checks don't happen also -- they do. So
you can think of CAS and role-based security as working together to
protect your assets :-)

-- Mary
MCW Technologies
http://www.mcwtech.com

On Mon, 23 Feb 2004 16:36:07 -0800, Novice
<6tc1ATqlinkDOTqueensuDOTca> wrote:

>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

  • RE: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Perm
    ... They are different types of permissions -- I was just grouping them together to distinguish them from role based security permissions, ... You could say that evidence based security is granting, and CAS is the subsystem that does the demanding if that's consistent with the ... I just tend to group the whole system together under the CAS umbrella. ... Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS? ...
    (microsoft.public.dotnet.security)
  • Re: Limiting exe permissions
    ... can't help but wonder why Microsoft didn't address this security ... > Much of the CAS effort has been around directly downloaded code (e.g.: ... > deal of complaint about the limitations that CAS already imposes. ... setting permissions of an executable should be as simple ...
    (microsoft.public.dotnet.security)
  • Re: Newbie security architecture question
    ... permissions in .Net are part of the Code Access Security system (CAS). ... > 2) Enforce security by putting up a different UI for each client based on ...
    (microsoft.public.dotnet.security)
  • Re: Newbie security architecture question
    ... permissions in .Net are part of the Code Access Security system (CAS). ... > 2) Enforce security by putting up a different UI for each client based on ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: .NET CAS vs OS security
    ... CAS won't come into play if your assembly is installed on the local file ... absolutely no interaction between CAS permissions and OS permissions. ... is layered over the top of the OS security and they are based on two totally ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ...
    (microsoft.public.dotnet.security)