none
CAS Security RRS feed

  • Question

  • I'm studying for the MCTS Framework exam (70-536), hoping to learn to use security properly, and have been fiddling with CAS security.  I can't seem to get it to work right:

     

    First of all, whenever I grant my assembly too few permissions for its assembly Request declarations, running the application brings a messagebox saying "'ProgramName' has encountered a problem and needs to close. We are sorry for the inconvenience.".  I thought that if there were a permission I required but didn't declare that I should get a more useful message saying what was missing?

     

    Second of all, I don't seem to be able to get "RequestOptional" working at all.  If I include a "RequestOptional" assembly attribute, then even if I grant "Everything" or "Full Trust" permission set to my assembly, I still get the message above about needing to close on program execution.

     

    Here are the permission declarations:

    [assembly: IsolatedStorageFilePermission(SecurityAction.RequestMinimum)]

    [assembly: UIPermission(SecurityAction.RequestMinimum)]

    [assembly: System.Data.SqlClient.SqlClientPermission(SecurityAction.RequestMinimum)]

    [assembly: SecurityPermission(SecurityAction.RequestMinimum)]

    [assembly: EnvironmentPermission(SecurityAction.RequestOptional)]

     

    In the CAS security code group I'm using, I've checked the box for "This policy level will have only the permissions from the permission set associated with this code group" and included unrestricted access for the following permissions in the permission set:

    Environment Variables

    Isolated Storage File

    Security

    SQL Client

    User Interface

     

    If I change so all 5 declarations are "RequestMinimum" (no "Request Optional"), app runs fine.  But with Request Optional it doesn't work, and even if I change to use permission set "Everything" or permission set "Full Trust", it STILL will not run.

     

    Can anyone tell me what I'm missing?

     

    Thank you very much for your help!
    Sunday, March 16, 2008 4:06 AM

Answers

  • These attributes are somewhat confusing in their naming and semantics. Check out these posts which should explain what's going on:

    http://blogs.msdn.com/shawnfa/archive/2005/09/14/466661.aspx
    http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx
    http://blogs.msdn.com/shawnfa/archive/2007/10/02/avoiding-assembly-level-declarative-security.aspx

    Monday, March 17, 2008 8:32 AM

All replies

  • These attributes are somewhat confusing in their naming and semantics. Check out these posts which should explain what's going on:

    http://blogs.msdn.com/shawnfa/archive/2005/09/14/466661.aspx
    http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx
    http://blogs.msdn.com/shawnfa/archive/2007/10/02/avoiding-assembly-level-declarative-security.aspx

    Monday, March 17, 2008 8:32 AM
  • Thank you for your post, but I'm unfortunately not seeing an answer on any of those sites to my questions - perhaps I did not express them sufficiently clearly.  I do understand that RequestOptional denies rights not explicitly requested in RequestOptional or RequestMinimum, and I am aware that there are some good reasons not to use declarative security.

     

    There are two things, however, that remain confusing to me:

     

    1) Why, when I hit a Declarative statement requesting more rights than I have, do I get the unhelpful messagebox "'ProgramName' has encountered a problem and needs to close. We are sorry for the inconvenience." instead of something saying what permission I lack?

     

    2) Even when I've included all the permissions the assembly seems to require per CAS setup in the declarative RequestMinimum and RequestOptional statements, the assembly still does not run if RequestOptional statement is present.  I don't see how I could be missing anything, because the assembly runs fine if I restrict it at the other end instead, so that CAS only gives it the essential five permissions, the same ones I'm trying using through declarative security.

     

    So, once again - the assembly runs fine if I cut its access down in CAS security to these permissions via .NET Configuration Tool, (I know that I really have succeeded in cutting its permissions, because if I take any one of these out of the permission set, it throws errors during program execution at tasks it is unable to complete)

    Environment Variables

    Isolated Storage File

    Security

    SQL Client

    User Interface

     

    But even if I leave it with those five permissions or more, and include ALL of those essential five permissions in assembly level RequestMinimum and RequestOptional statements, having at least one RequestOptional, the assembly will not run - instead it errs with aforementioned "'Program Name' has encountered a problem... " message.  Why won't it run?  I've given it everything it needs, and I know so because it runs fine when those 5 permissions are the only ones CAS allows it.  Why are they no longer good enough when it's restricting its own security?  Here are the declarations I put on my assembly:

    [assembly: IsolatedStorageFilePermission(SecurityAction.RequestMinimum)]

    [assembly: UIPermission(SecurityAction.RequestMinimum)]

    [assembly: System.Data.SqlClient.SqlClientPermission(SecurityAction.RequestMinimum)]

    [assembly: SecurityPermission(SecurityAction.RequestMinimum)]

    [assembly: EnvironmentPermission(SecurityAction.RequestOptional)]

     

    These seem to me to line up to the five items that I had to include in the CAS permission set for the assembly to run correctly.  Does Environment Variables somehow not correspond to EnvironmentPermission?  Or Isolated Storage File not correspond to IsolatedStorageFilePermission?  Etc..???  Why won't the assembly run?

     

    Thank you very much for your aid.

    Tuesday, March 18, 2008 3:40 AM
  • Hello,

    This was an interesting question and requires a bit of explanation. I'm certainly not a specialist and am just trying to reflect using available documentation. First, the pointers that Greg included do indeed shed a light on what's going on.
    An important thing to understand is the difference between allowed permissions and granted permissions.
    - Allowed permissions is what the executionengine calculates by iterating through the CAS policies (Enterprise, MAchine and User)
    - Granted permissions is what the assembly actually keeps by performing some additinal calculations based on assembly level declarative security actions starting from the allowed permissions
      An MSDN article explains (Determining the Granted Permissions -> http://msdn.microsoft.com/en-us/library/9xyehxdk(VS.71).aspx):
    1. The runtime computes the allowed permissions for the assembly and insures that the assembly has permission to execute. If permission to execute is not present, the runtime throws a PolicyException and the code is not allowed to run.
    2. The runtime determines whether the set of required permissions is a subset of the allowed permission set. If not, the runtime throws a PolicyException and the code is not allowed to run.
    3. The runtime intersects the optional requested permissions with the allowed permission set. If optional permissions are not requested, then the optional PermissionSet is assumed to be FullTrust.
    4. The runtime unions the result of step 3 with the minimum requested permissions.
    5. Finally, the runtime subtracts any permissions that are refused from the result of step 4.

    So back to your code.

    You request a specific assembly level security action by using:  [assembly: IsolatedStorageFilePermission(SecurityAction.RequestMinimum)]. Using it like this is saying the assembly requires the presence of the permission in the allowed permission set using the defaults for the IPermission implementation. (you do not include additonal parameters at the level of the permission attribute e.g. Unrestricted = true)

    So as long as you use only the RequestMinimum actions and the requested permissions are in the allowed permissions set everything is OK and your application works.

    Now you change one of the RequestMinimum to RequestOptional, look at point 3 in the list which says the runtime intersects the optional permissions with the allowed permissions. So in your case you allow five permissions in the CAS policy (IsolatedStorage, UIPermission, SqlClientPermission, SecurityPermission and EnvironmentPermission) and by including the optional EnvironmentPermission at assembly level you intersect and wipe the other four away (those with unrestricted as indicated in the CAS policy). Point 4 indicates that required permissions (in their default state) are unioned with the resulting permissionset from point 3, so you add back the four remaining permissionsets (but with their default state). UIPermission has no specific settings and security engine throws an exception.

    If you would change [assembly: UIPermission(SecurityAction.RequestMinimum)] to [assembly: UIPermission(SecurityAction.RequestMinimum, Unrestricted = true)] the application will run fine.

    One remark, it is strange the default SecurityPermission allows to execute code without even indicating so, this is something I still have trouble figuring out.

    I hope this helps you out a bit (it certainly gave me the opportunity to extend my CAS knowledge a bit)

    Regards,

    Wilke


    Consultant
    Wednesday, August 6, 2008 10:43 AM