SecurityAction RequestOptional, RequestRefuse, & more

[Guest]

Hi;

I have a DLL that has events that applications can register with. When those
delegates fire, my DLL is in the permission call stack. In this case here is
where I get confused.

If I use SecurityAction.RequestMinimum- then that permission can be used by
delegates my event calls.
If I use SecurityAction.RequestOptional - then that permission may be used
by delegates my event calls.
If I use SecurityAction.RequestRefuse - then that permission can NOT be used
by delegates my event calls.

But what about a permission that my DLL does not need - but I want to allow
in the delegates. Is there any way to set that? It seems that would be useful
information.

It also seems that not listing a specific permission is the same as saying
RequestOptional???

 

[Peter Huang [MSFT]]

Hi

Here is some information about the SecurityAction.

the RequestMinimum the give your dll the permission.

RequestMinimum
You can use SecurityAction.RequestMinimum method along with declarative
permission attributes to specify the minimum set of permissions your
assembly needs to run. For example, if your assembly needs to access the
registry, but only needs to retrieve configuration data from a specific
key, use an attribute similar to the following:

[assembly: RegistryPermissionAttribute(
SecurityAction.RequestMinimum,
Read=@"HKEY_LOCAL_MACHINE\SOFTWARE\YourApp")]

If you know up front that your code will run in a full trust environment
and will be granted the full set of unrestricted permissions, using
RequestMinimum is less important. However, it is good practice to specify
your assembly's permission requirements.

Note Permission attributes accept a comma-delimited list of properties
and property values after the mandatory constructor arguments. These are
used to initialize the underlying permission object. A quick way to find
out what property names are supported is to use Ildasm.exe on the assembly
that contains the permission attribute type.
RequestOptional
If you use SecurityAction.RequestOptional method, no other permissions
except those specified with SecurityAction.RequestMinimum and
SecurityAction.RequestOptional will be granted to your assembly, even if
your assembly would otherwise have been granted additional permissions by
code access security policy.

RequestRefused
SecurityAction.RequestRefuse allows you to make sure that your assembly
cannot be granted permissions by code access security policy that it does
not require. For example, if your assembly does not call unmanaged code,
you could use the following attribute to ensure code access security policy
does not grant your assembly the unmanaged code permission.

[assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse,
UnmanagedCode=true)]

......
If you use RequestOptional, the set of permissions that are specified with
RequestOptional and RequestMinimum are INTERSECTED with the permission
grant given to your assembly by policy.

For detailed information, you may try to take a look at the link below.
Code Access Security in Practice
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html
/secmod81.asp

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Nicole Calinoiu]

If you use SecurityAction.RequestOptional method, no other permissions
except those specified with SecurityAction.RequestMinimum and
SecurityAction.RequestOptional will be granted to your assembly, even if
your assembly would otherwise have been granted additional permissions by
code access security policy.

That's not quite the whole story. SecurityPermission\Execution and identity
permissions are implictly conserved when using RequestOptional. It is
necessary to use RequestRefuse attributes if one wishes to reject these
permissions.

 

[Nicole Calinoiu]

But what about a permission that my DLL does not need - but I want to
allow
in the delegates. Is there any way to set that? It seems that would be
useful
information.

Assertion is the usual way for bypassing permission limitations imposed
elsewhere on the call stack (whether due to limited permission grants or
constraining stack walk modifiers). However, as I mentioned in your earlier
thread, assertion is potentially dangerous, and I wouldn't recommend its use
until you understand those dangers thoroughly and know how to protect
against potential luring attacks.

It also seems that not listing a specific permission is the same as saying
RequestOptional???

Not at all. I would once again encourage you to read Shawn Farkas' coverage
of this topic at
http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx if you are
interested in understanding how the three varieties of assembly-level
permission attributes work together.

 

[Guest]

Thank you - this helps a ton.

I have a DLL that other apps call and I wanted to be very specific about
exactly it did so users could see what access it needs. However it has an
event that other DLLs can register with and when that event fires, my DLL is
in the call stack.

So it looks like I should only declare RequestMinimum and leave the
RequestOptional to the default FullTrust. I was assuming more functionality
than exists in the security model.

 

[Nicole Calinoiu]

Thank you - this helps a ton.

I have a DLL that other apps call and I wanted to be very specific about
exactly it did so users could see what access it needs. However it has an
event that other DLLs can register with and when that event fires, my DLL
is
in the call stack.

So it looks like I should only declare RequestMinimum and leave the
RequestOptional to the default FullTrust.

Actually, that's not strictly necessary. If you want to allow your assembly
to run with full trust while still using RequestOptional attributes for the
purpose of providing information to consumers and/or CAS admins, just add a
RequestOptional for unrestricted permissions (full trust) in addition to
your existing assembly-level permission attributes. e.g.:

[assembly: PermissionSet(SecurityAction.RequestOptional, Unrestricted =
true)]

I was assuming more functionality
than exists in the security model.

Actually, you were assuming _different_ (an perhaps even less)
functionality. RequestOptional simply has side effects that you weren't
expecting, and one could very well argue that the option is poorly named
because of this. However, the "unexpected" functionality that it exposes is
quite useful, and at least some of us do take advantage of it in order to
use white-listing rather than black-listing in our permissions declarations.