Re: Identity Permission and Code Access Permission classes

From: Shawn Farkas (shawnfa_at_online.microsoft.com)
Date: 08/24/04


Date: Tue, 24 Aug 2004 21:55:58 GMT

I'm working on a several-part blog series on Assert .... however a lot of the concepts will apply to the other stack modifiers as well. You can find
parts 1 and 2 up already:

http://blogs.msdn.com/shawnfa/archive/2004/08/23/219155.aspx
http://blogs.msdn.com/shawnfa/archive/2004/08/24/219725.aspx

-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.  
--------------------
>From: "Nicole Calinoiu" <nicolec@somewhere.net>
>References:  <4E09C5AF-CECE-4C0A-BBD4-374A3E55DB14@microsoft.com> <uJjZjRthEHA.356@tk2msftngp13.phx.gbl> <D701198F-39CF-
4E3E-9C89-8EE08D9E0BBC@microsoft.com> <9E20FDC3-2635-4345-A12C-04DC95205C4F@microsoft.com> <udhxGg3hEHA.3264
@tk2msftngp13.phx.gbl> <D9FE3455-590E-4F0E-8C7F-99B089333527@microsoft.com>
>Subject: Re: Identity Permission and Code Access Permission classes
>Date: Tue, 24 Aug 2004 14:57:12 -0400
>Lines: 192
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Newsreader: Microsoft Outlook Express 6.00.2900.2149
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2149
>X-RFC2646: Format=Flowed; Original
>Message-ID: <uqT0zwgiEHA.596@TK2MSFTNGP11.phx.gbl>
>Newsgroups: microsoft.public.dotnet.security
>NNTP-Posting-Host: modemcable050.34-203-24.mc.videotron.ca 24.203.34.50
>Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
>Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.security:7217
>X-Tomcat-NG: microsoft.public.dotnet.security
>
>The most common use of assert and deny is when mapping from one permission 
>to another.  For example, let's say a library contains a method that sets 
>the system clock via a call to unmanaged code.  Obviously, the library 
>requires UnmanagedCode permission, but it might be excessive to require that 
>its callers also possess this permission.  In this case, the method that 
>alters the system clock might assert UnmanagedCode permission in order to 
>bypass the permission check for its caller then revert the assertion 
>immediately thereafter.
>
>However, this is usually still not safe enough since it would be a bit 
>ridiculous to expose the clock-setting functionality to all partially 
>trusted code.  In order to add reasonable protection, the method could 
>demand some alternate permission (e.g.: a custom resource permission) prior 
>to making the assertion that allows the unmanaged code to be run.  The 
>general pattern for this is:
>
>1.  Demand a permission that maps well to the intended target action of the 
>code to be executed.
>2.  Assert the permission(s) that the target code requires but that the 
>calling code may acceptably lack.
>3.  Run the target code.
>4.  Revert the assertion.
>
>HTH,
>Nicole
>
>
>
>"Novice" <6tc1ATqlinkDOTqueensuDOTca> wrote in message 
>news:D9FE3455-590E-4F0E-8C7F-99B089333527@microsoft.com...
>> I'm really just trying to get a better grasp of when it would be 
>> appropriate
>> to use the Stack Walk Modifiers.  I guess, they are appropriate just to
>> lock-down your application/libraries - but that ultimately it is the
>> responsibility of the computer hosting the application to ensure access is
>> limited.
>>
>> What are your thoughts?
>>
>> Novice
>>
>> "Nicole Calinoiu" wrote:
>>
>>> I'm still not sure what your ultimate goal is here, so it's a bit 
>>> difficult
>>> to say whether the information in the P&P document is really relevant. 
>>> It
>>> would help quite a bit if you could better describe why you want to 
>>> protect
>>> the contents of this directory and against what type(s) of threat you
>>> believe it requires protection.
>>>
>>> My guess so far has been that this is a configuration directory for your
>>> application, and you want to protect its contents from modification by 
>>> any
>>> code other than your own.  If so, within-code protections (whether
>>> imperative or declarative) are only a partial solution, addressing only
>>> possible luring of your code to perform undesired actions.  However, even
>>> wrt to this particular goal, use of StrongNamePermission alone isn't
>>> necessarily particularly useful since it's trivial to bypass.  It can,
>>> however, be sufficient to counter certain types of threats.  So... 
>>> Exactly
>>> what kind of potential misuse are you trying to protect this directory
>>> against?
>>>
>>>
>>> "Novice" <6tc1ATqlinkDOTqueensuDOTca> wrote in message
>>> news:9E20FDC3-2635-4345-A12C-04DC95205C4F@microsoft.com...
>>> >I believe this is information I was looking for:
>>> > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp
>>> >
>>> > Go to the section "Using Stack Walk Modifiers".  Basically it states 
>>> > that
>>> > you can use the security policy, but that you can also achieve the same
>>> > effect programmatically in your code.
>>> >
>>> > If the above seems inconsistent with what I was originally asking - 
>>> > please
>>> > let me know because it may be that I misunderstand the documentation.
>>> >
>>> > Thanks,
>>> > Novice
>>> >
>>> > "Novice" wrote:
>>> >
>>> >> What I meant is that I could achieve this same functionality by 
>>> >> writing
>>> >> code
>>> >> (imperatively) such that:
>>> >> if (publicKeyEqualsExpectedValue){
>>> >>   allowWriteToHardDisk();
>>> >> }
>>> >>
>>> >> And again the same code could be written in declarative statements. 
>>> >> Of
>>> >> course the assumption is that you have access to the source code
>>> >> otherwise
>>> >> you wouldn't be able to write the declarative or imperative statements 
>>> >> to
>>> >> begin with.
>>> >>
>>> >> That is why I said it isn't "clean" since I would see putting the 
>>> >> above
>>> >> statement into every assembly as a hack.
>>> >>
>>> >> But my real question was if there was a way to create a declarative
>>> >> statement like the one I posted:
>>> >> [StrongNameIdentityPermission(SecurityAction.LinkDemand,
>>> >> 
>>> >> PublicKey="00240000048...97e85d098615")]
>>> >>
>>> >> And add something to the above or following the above that would also
>>> >> indicate that the application could only write to:
>>> >> c:\somedirectory\
>>> >> if it had the above PublicKey.
>>> >>
>>> >> I.E. is there a way to do the above in the source code for an 
>>> >> application
>>> >> and use the PublicKey (a piece of evidence) to restrict an assembly's
>>> >> privileges/permissions.
>>> >>
>>> >> I think this could be achieve using the code access permission request
>>> >> operations (request, assert and deny).  This of course assumes that 
>>> >> the
>>> >> security policy would allow that level - however, assuming the policy
>>> >> allowed
>>> >> it - couldn't you write code such that you deny write access to that
>>> >> directory if the PublicKey isn't what you require?
>>> >>
>>> >> Thanks,
>>> >> Novice
>>> >>
>>> >>
>>> >> "Nicole Calinoiu" wrote:
>>> >>
>>> >> > Not sure what you mean by "I know this could be done using 
>>> >> > imperative
>>> >> > security" since, well, it's not. <g>
>>> >> >
>>> >> > Setting a machine to only allow access to a directory by assemblies
>>> >> > signed
>>> >> > with a specified key is certainly possible, but it's not done by
>>> >> > imperative
>>> >> > or declarative CAS checks in some other assembly's code.  It's only
>>> >> > accomplished by setting policy.  Otherwise, code that doesn't pass
>>> >> > through
>>> >> > your application wouldn't be subject to the limitation.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > "Novice" <6tc1ATqlinkDOTqueensuDOTca> wrote in message
>>> >> > news:4E09C5AF-CECE-4C0A-BBD4-374A3E55DB14@microsoft.com...
>>> >> > > If I wanted to ensure that a particular assembly (or set of
>>> >> > > assemblies) as
>>> >> > > dictated by something in their evidence got certain code access
>>> >> > > permissions
>>> >> > > could I do this both in the security policy on the host machine or
>>> >> > > using
>>> >> > > declarative security (I know this could be done using imperative
>>> >> > > security -
>>> >> > > but it is not as "clean" as declarative security).
>>> >> > >
>>> >> > > To be more specific I would like to write a declarative security
>>> >> > > statement
>>> >> > > like the one below:
>>> >> > > [StrongNameIdentityPermission(SecurityAction.LinkDemand,
>>> >> > >
>>> >> > > PublicKey="00240000048...97e85d098615")]
>>> >> > >
>>> >> > > such that only assemblies with a particular PublicKey (like the 
>>> >> > > one
>>> >> > > above)
>>> >> > > could be given rights to access "c:\somedirectory\"
>>> >> > >
>>> >> > > I would prefer to do this using declarative security statements - 
>>> >> > > a
>>> >> > > second
>>> >> > > question is whether this would be possible using the security
>>> >> > > administrator
>>> >> > > on the local machine.
>>> >> > >
>>> >> > > Thanks,
>>> >> > > Novice
>>> >> >
>>> >> >
>>> >> >
>>>
>>>
>>> 
>
>
>


Relevant Pages

  • Re: security/strong name/zones clarification needed
    ... Does the Assert code go in its ... >>this AppDomain needs to be setup before your assembly can ... >>will recieve the permission grant you expect (in this ... All my assemblies are strong named. ...
    (microsoft.public.dotnet.security)
  • Re: Code Acess Security
    ... Assert is used to prevent a stack walk. ... - My assembly is granted permission A as well as the permission to Assert ... Note that there are some major assemblies in the ...
    (microsoft.public.dotnet.security)
  • Re: Identity Permission and Code Access Permission classes
    ... The most common use of assert and deny is when mapping from one permission ... to making the assertion that allows the unmanaged code to be run. ... and you want to protect its contents from modification by ...
    (microsoft.public.dotnet.security)
  • Re: security exception for aspx page
    ... You can't just inherit, you have wrap. ... assert each permission that their code demands in order to block the stack ... you just create a permission object of the same type that is ... or just a class that delegates the functions to 3rd party control ...
    (microsoft.public.dotnet.security)
  • Re: (OT) War is hell, but not like it once was
    ... Um, no, but I believe that our government should take whatever steps ... to protect us. ... Only a complete idiot would assert such a thing from my ...
    (alt.autos.toyota)