Runtime Security Policy question

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I THOUGHT I COULD BLOCK CODE ACCESS SIMPLY BY RESTRICTING ACCESS VIA THE
FRAMEWORK CONFIGURATION MANAGER. MY EXPERMENT BELOW HAS CONFUSED ME.

I attributed a DLL called "Filer" at the assembly level as follows:

[assembly:FileIOPermission(SecurityAction.RequestMinimum,Unrestricted=true)]

The Filer.dll contains a class called FileOpener.

I compiled "Filer.dll" and referenced it from a Windows Form Project.

In Framework Config Tool, I created a Code Group named "Test" as a child of
the "All Code" code group at the Machine Level, Imported Filer.dll with a
Hash Membership Condition, set Policy Level to Exclusive, and set the
Permission Set to the "Nothing" Permission Set. I tested the Permission Level
with the "Evaluate Assembly" option and was informed I had no Permissions.

AS EXPECTED, I ran the form and got an
System.Security.Policy.PolicyException when I instantiated the
Filer.FileOpener class.

I THEN REMOVED THE FILER.DLL ATTRIBUTE mentioned above
([assembly:FileIOPermission( SecurityAction.RequestMinimum,
Unrestricted=true)])

....from the Filer.dll and recompiled, rereferenced in the Form app, in
Framework Config tool, reImported the Test Code Group hash membership
condition and left all other Security Policy settings the same. I tested the
Permission Level with the "Evaluate Assembly" option and was informed I had
no Permissions.

AS UNEXPECTED, I ran the form and DID NOT get an
System.Security.Policy.PolicyException when I instantiated the "filer.dll"
FileOpener class. In fact I got no Exception!

I would expect no exception if I had made a mistake in reImporting the
Filer.dll in the Framework Config Tool, but I didn't. In fact I reversed the
process by reattributing the Filer.dll, recompiling, rereferencing in the
Form app, in Framework Config tool, reImported the Test Code Group hash
membership condition and left all other Security Policy settings the same. I
tested the Permission Level with the "Evaluate Assembly" option and was
informed I had no Permissions.

AS EXPECTED, I ran the form and got an
System.Security.Policy.PolicyException when I instantiated the
Filer.FileOpener class.

This leads me to believe that FRAMEWORK CONFIGURATION MANAGER Runtime
Security Policy settings do not affect components that have not been
attributed to request Permissions...and instead Permission Calculation only
comes into play when code has been attributed with permission requests.

This goes against what I read about the subject. Can you see what I am
missing?
 
Please disregard earlier post...I was having an issue with the union of
Machine Level Permissions, I was not expecting, which was the reason for the
lack of Policy Exceptions...sorry for the wordy distraction...




Dave Boal said:
I THOUGHT I COULD BLOCK CODE ACCESS SIMPLY BY RESTRICTING ACCESS VIA THE
FRAMEWORK CONFIGURATION MANAGER. MY EXPERMENT BELOW HAS CONFUSED ME.

I attributed a DLL called "Filer" at the assembly level as follows:

[assembly:FileIOPermission(SecurityAction.RequestMinimum,Unrestricted=true)]

The Filer.dll contains a class called FileOpener.

I compiled "Filer.dll" and referenced it from a Windows Form Project.

In Framework Config Tool, I created a Code Group named "Test" as a child of
the "All Code" code group at the Machine Level, Imported Filer.dll with a
Hash Membership Condition, set Policy Level to Exclusive, and set the
Permission Set to the "Nothing" Permission Set. I tested the Permission Level
with the "Evaluate Assembly" option and was informed I had no Permissions.

AS EXPECTED, I ran the form and got an
System.Security.Policy.PolicyException when I instantiated the
Filer.FileOpener class.

I THEN REMOVED THE FILER.DLL ATTRIBUTE mentioned above
([assembly:FileIOPermission( SecurityAction.RequestMinimum,
Unrestricted=true)])

...from the Filer.dll and recompiled, rereferenced in the Form app, in
Framework Config tool, reImported the Test Code Group hash membership
condition and left all other Security Policy settings the same. I tested the
Permission Level with the "Evaluate Assembly" option and was informed I had
no Permissions.

AS UNEXPECTED, I ran the form and DID NOT get an
System.Security.Policy.PolicyException when I instantiated the "filer.dll"
FileOpener class. In fact I got no Exception!

I would expect no exception if I had made a mistake in reImporting the
Filer.dll in the Framework Config Tool, but I didn't. In fact I reversed the
process by reattributing the Filer.dll, recompiling, rereferencing in the
Form app, in Framework Config tool, reImported the Test Code Group hash
membership condition and left all other Security Policy settings the same. I
tested the Permission Level with the "Evaluate Assembly" option and was
informed I had no Permissions.

AS EXPECTED, I ran the form and got an
System.Security.Policy.PolicyException when I instantiated the
Filer.FileOpener class.

This leads me to believe that FRAMEWORK CONFIGURATION MANAGER Runtime
Security Policy settings do not affect components that have not been
attributed to request Permissions...and instead Permission Calculation only
comes into play when code has been attributed with permission requests.

This goes against what I read about the subject. Can you see what I am
missing?
Click to expand...
 
Back
Top