Asserting the permission to execute unmanaged code

  • Thread starter Thread starter Michel Walsh
  • Start date Start date
M

Michel Walsh

Hi,


What is the "declaration" (class) I need to assert the permission that
my code can run unmanaged code.

I have:


================
[System.Runtime.InteropServices.DllImport("KERNEL32")]

private static extern bool QueryPerformanceCounter( ref long

lpPerformanceCount);

[System.Runtime.InteropServices.DllImport("KERNEL32")]

private static extern bool QueryPerformanceFrequency( ref long

lpFrequency);

====================

and before calling QueryPerformanceCounter, I want to Assert() the
permission, but I completely miss the syntax, having not even a real clue
about the class to use (for illustration, SecurityAction, but probably
something else):

================

static Timings()

{


// Initialize the frequency

CodeAccessPermission perm = new SecurityAction??? ; // <<< HERE

perm.Assert();

dummy=QueryPerformanceFrequency( ref frequency);

dummy=QueryPerformanceCounter(ref fpsStartingCounter);

perm.RevertAssert();

....

==============



Thanks in advance,

Vanderghast, Access MVP
 
Michel,

You want to create an instance of the SecurityPermission class, passing
in the UnmanagedCode value from the SecurityPermissionFlag enumeration.
From there, you can call Assert.

Hope this helps.
 
This should do the trick (in a slightly safer form <g>):

IStackWalk perm = new SecurityPermission
SecurityPermissionFlag.UnmanagedCode);
perm.Assert();

try
{
dummy = QueryPerformanceFrequency(ref frequency);
dummy = QueryPerformanceCounter(ref fpsStartingCounter);
}
finally
{
CodeAccessPermission.RevertAll();
}
 
Sorry, weird copy-paste artifact. That should have been:

IStackWalk perm = new
SecurityPermission(SecurityPermissionFlag.UnmanagedCode);
perm.Assert();
....
 
Hi Nicole,


That is here that you hide yourself in these days... :-)

When I compared with FileIOPermission, which takes two arguments,
the first argument allowing to Append permissions as example, the fact that
SecurityPermission accepts just one argument, not two, throw me back, but
now that I think about it, that makes sense too.


Is there a relatively good reference on similar security aspects,
with C#; I already have "Professional C#" (Wrox, first edition), and, sure,
the help file.



Thanks again, and to Nicholas too.

Vanderghast, Access MVP



Nicole Calinoiu said:
This should do the trick (in a slightly safer form <g>):

IStackWalk perm = new SecurityPermission
SecurityPermissionFlag.UnmanagedCode);
perm.Assert();

try
{
dummy = QueryPerformanceFrequency(ref frequency);
dummy = QueryPerformanceCounter(ref fpsStartingCounter);
}
finally
{
CodeAccessPermission.RevertAll();
}


Michel Walsh said:
Hi,


What is the "declaration" (class) I need to assert the permission that
my code can run unmanaged code.

I have:


================
[System.Runtime.InteropServices.DllImport("KERNEL32")]

private static extern bool QueryPerformanceCounter( ref long

lpPerformanceCount);

[System.Runtime.InteropServices.DllImport("KERNEL32")]

private static extern bool QueryPerformanceFrequency( ref long

lpFrequency);

====================

and before calling QueryPerformanceCounter, I want to Assert() the
permission, but I completely miss the syntax, having not even a real clue
about the class to use (for illustration, SecurityAction, but probably
something else):

================

static Timings()

{


// Initialize the frequency

CodeAccessPermission perm = new SecurityAction??? ; // <<< HERE

perm.Assert();

dummy=QueryPerformanceFrequency( ref frequency);

dummy=QueryPerformanceCounter(ref fpsStartingCounter);

perm.RevertAssert();

...

==============



Thanks in advance,

Vanderghast, Access MVP
Click to expand...
Click to expand...
 
You could also put the two calls into their own internal class and apply the

[SuppressUnmanagedCodeSecurity]

attribute to the class. This will stop the stack walk from starting in the first place for these two interop calls.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

This should do the trick (in a slightly safer form <g>):

IStackWalk perm = new SecurityPermission
SecurityPermissionFlag.UnmanagedCode);
perm.Assert();

try
{
dummy = QueryPerformanceFrequency(ref frequency);
dummy = QueryPerformanceCounter(ref fpsStartingCounter);
}
finally
{
CodeAccessPermission.RevertAll();
}
 
Hi,


That is exactly what does one of my reference, and I was wondering what
that code was really implying. Definitively, that is preferable in this
case, where high precision timing is expected.

Thanks,
Vanderghast, Access MVP
 
Michel Walsh said:
Hi Nicole,


That is here that you hide yourself in these days... :-)
Click to expand...

Yeah, it's been quite some time since I used that "other" product for
When I compared with FileIOPermission, which takes two arguments,
the first argument allowing to Append permissions as example, the fact
that SecurityPermission accepts just one argument, not two, throw me back,
but now that I think about it, that makes sense too.


Is there a relatively good reference on similar security aspects,
with C#; I already have "Professional C#" (Wrox, first edition), and,
sure, the help file.
Click to expand...

Last time I went book shopping, "Programming .NET Security" (Freeman and
Jones, from O'Reilly) was the best I found. That was about a year ago, so
there might be something better out by now. Also, I never actually got
around to the reading the thing, so I can't give a real recommendation. If
you would like to borrow it for a bit (I _do_ intend to read it eventually
Thanks again, and to Nicholas too.

Vanderghast, Access MVP



Nicole Calinoiu said:
This should do the trick (in a slightly safer form <g>):

IStackWalk perm = new SecurityPermission
SecurityPermissionFlag.UnmanagedCode);
perm.Assert();

try
{
dummy = QueryPerformanceFrequency(ref frequency);
dummy = QueryPerformanceCounter(ref fpsStartingCounter);
}
finally
{
CodeAccessPermission.RevertAll();
}


Michel Walsh said:
Hi,


What is the "declaration" (class) I need to assert the permission
that my code can run unmanaged code.

I have:


================
[System.Runtime.InteropServices.DllImport("KERNEL32")]

private static extern bool QueryPerformanceCounter( ref long

lpPerformanceCount);

[System.Runtime.InteropServices.DllImport("KERNEL32")]

private static extern bool QueryPerformanceFrequency( ref long

lpFrequency);

====================

and before calling QueryPerformanceCounter, I want to Assert() the
permission, but I completely miss the syntax, having not even a real
clue about the class to use (for illustration, SecurityAction, but
probably something else):

================

static Timings()

{


// Initialize the frequency

CodeAccessPermission perm = new SecurityAction??? ; // <<< HERE

perm.Assert();

dummy=QueryPerformanceFrequency( ref frequency);

dummy=QueryPerformanceCounter(ref fpsStartingCounter);

perm.RevertAssert();

...

==============



Thanks in advance,

Vanderghast, Access MVP
Click to expand...
Click to expand...
Click to expand...
 
It would probably be a good idea to add a level of abstraction to that
arrangement since it has a rather high likelihood of becoming less secure
with subsequent modification. A somewhat safer appropach would be to make
the interop calls private to the new internal class, with internal method
wrappers exposed for calling the private methods. This would at least
ensure that a checkpoint exists for screening all callers to the unmanaged
code, should this ever become necessary or desirable (i.e.: if security
concerns are ever found to outweigh performance concerns).
 
It depends on the size of the library that is performing this of course. On the basis that this class is internal if the library is not large then, as you in control of the code, then changing te level of abstraction is not necessarily a huge deal. Adding a level of abstraction adds complexity to the library creator (not the consumer who is insulated as this class is internal) which may or may not be justified in the the component in question.

I wouldn't at all suggest adding that attribute to a public class.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

It would probably be a good idea to add a level of abstraction to that
arrangement since it has a rather high likelihood of becoming less secure
with subsequent modification. A somewhat safer appropach would be to make
the interop calls private to the new internal class, with internal method
wrappers exposed for calling the private methods. This would at least
ensure that a checkpoint exists for screening all callers to the unmanaged
code, should this ever become necessary or desirable (i.e.: if security
concerns are ever found to outweigh performance concerns).
 
At the time that the p/invoke methods are moved into a separate class marked
with SuppressUnmanagedCodeSecurityAttribute, adding the wrappers would be a
trivial operation since the methods were previously private to their source
class, and every single call to the methods in that source class needs to be
changed to point at the new class anyway. This holds true regardless of the
the size of the library.

The reason that I suggested adding the wrappers wasn't merely for typical
abstraction reasons. Use of SuppressUnmanagedCodeSecurityAttribute is risky
and requires some minimal precautions (or perhaps even the "extreme care"
recommended by the documentation on the attribute <g>). These include
precautions against one's own possible future mistakes, the pool of which
immediately grows when the visibility of the methods is increased.
 
Back
Top