Hi Dave,

I think how to config the security setting should be depend on your
scenario.
The CAS worked based on Evidence(e.g. Strongname, url....), and it is used
to control Restrict which code can call your code, what your code can do.
You should make sure what your assembly A will do and what not do. Then the
other assembly B call the A, it will have evidence so that CLR will get it
permission dependent on your setting. But no matter what permission the B
have, it can not call the A's method(or via delegate, as long as the DLL
code is on the call stack), if we have set the A have no the permisson.

Also if certain Assembly C have another evidence want to call A, but C have
no the permisson that A have, then the C call A's method will still fail.

So I strongly recommended your look through all the links below and consult
the .NET Security Book.

Avoid Using APTCA
If you use APTCA, your code is immediately more vulnerable to attack and,
as a result, it is particularly important to review your code for security
vulnerabilities. Use APTCA only where it is strictly necessary.

In the context of server-side Web applications, use APTCA whenever your
assembly needs to support partial trust callers. This situation can occur
in the following circumstances:

Your assembly is to be called by a partial trust Web application. These are
applications for which the <trust> level is set to something other than
Full. For more information about partial trust Web applications and using
APTCA in this situation, see Chapter 9, "Using Code Access Security with
ASP.NET."
Your assembly is to be called by another assembly that has been granted
limited permissions by the code access security administrator.
Your assembly is to be called by another assembly that refuses specific
permissions by using SecurityAction.RequestRefuse or
SecurityAction.RequestOptional. These make the calling assembly a partial
trust assembly.
Your assembly is to be called by another assembly that uses a stack walk
modifier (such as Deny or PermitOnly) to constrain downstream code.

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.

Authorizing Code
Code access security allows you to authorize the code that calls your
assembly. This reduces the risk of malicious code successfully calling your
code. For example, you can use identity permissions to restrict calling
code based on identity evidence, such as the public key component of its
strong name. You can also use explicit code access permission demands to
ensure that the code that calls your assembly has the necessary permissions
to access the resource or perform the privileged operation that your
assembly exposes.

Usually, you do not explicitly demand code access permissions. The .NET
Framework classes do this for you, and a duplicate demand is unnecessary.
However, there are occasions when you need to issue explicit demands, for
example, if your code exposes a custom resource by using unmanaged code or
if your code accesses cached data. You can authorize code in the following
ways:

Restrict which code can call your code.
Restrict inheritance.
Consider protecting cached data.
Protect custom resources with custom permissions.

Code Access Security in Practice
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html
/secmod81.asp


Providing information for Security Policy administrators has side effects
RequestMinimum and RequestOptional were discussed in my previous article.
RequestMinimum doesn't cause any change to Security Policy. In minimum.cs
the UIPermisssion's AllWindows permission was requested:

[assembly:UIPermission(SecurityAction.RequestMinimum,
Window = UIPermissionWindow.AllWindows)]

If you change the UIPermission in SamplePS Permission Set to "No Windows",
the code fails to run. However, the name Request is potentially misleading.
If you don't have the permission, your program will fail with a
PolicyException before your code ever runs. RequestMinimum tells the system
that you absolutely must have these permissions to run. If that's not the
case, you're better off not using a RequestMinimum. Check what permissions
you have with a Demand, and take the appropriate recovery path in your code
if you don't have the permissions.

RequestOptional is even trickier. The file optional.cs in the
RequestOptional sample has two RequestOptional actions commented out:

//[assembly:UIPermission(SecurityAction.Request
Optional, Window = UIPermissionWindow.AllWindows)]
//[assembly:FileIOPermission(SecurityAction.Request
Optional, All = @"c:\")]

If you run the program, it works. Uncomment one of the actions, and run the
program. You can't execute the action the other request refers to!
Uncomment both. The program runs! Change one of the actions to a
RequestMinimum¡ªthe program still runs. RequestOptional implicitly refuses
all permissions that weren't in a RequestMinimum or a RequestOptional. It's
as if a RequestRefuse were entered for every other permission covered by
your system's Security Policy. No mere request, this Security Action,
either. Note that the failure resulting from a RequestOptional, however,
causes a SecurityException to be thrown when the action with the
unavailable permission is requested. RequestOptional never implicitly
refuses the Execution permission.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs03/ht
ml/vs03b1.asp

Programming .NET Code Access Security
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs03/ht
ml/hcvs03a11.asp

Understanding .NET Security Actions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnhcvs03/ht
ml/vs03b1.asp

Requesting Optional Permissions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconrequestingoptionalpermissions.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.

Hi;

Ok, I think I'm understanding this better. This is what I get out of reading
the links you sent me:

1. Normally all you should use is RequestMinimum and leave the rest to
default.
2. If for any reason you use RequestOptional then everything not
specifically listed becomes RequestRefuse.
2b. This does not happen for a RequestRefuse - correct?
3. If you have any RequestOptional or RequestRefuse, the code becomes APTCA
- which is bad
3b. I like the idea of setting
[assembly:SecurityPermission(SecurityAction.RequestRefuse,
UnmanagedCode=true)] - but should not as that makes it APTCA - correct?
3c. I had [assembly:SecurityPermission(SecurityAction.RequestRefuse,
UnmanagedCode=true)] set in the DLL and did not get a permission error - any
idea why?
3d. Out of curiosity - why does this make code APTCA?
4. This all started in my case because I added
[assembly:FileIOPermission(SecurityAction.RequestOptional,
Unrestricted=true)] since my code needs I/O access only for some API calls.
4b.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod81.asp
says "The best way to communicate the permission requirements of your code is
to use assembly level declarative security attributes to specify minimum
permission requirements. These are normally placed in Assemblyinfo.cs or
Assemblyinfo.vb" - but it seems there is no way to list optional permissions
that my code may need???

--
thanks - dave


[quoted text, click to view]