Asserting the permission to execute unmanaged code

[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

[Nicholas Paldino [.NET/C# 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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:u9**************@TK2MSFTNGP14.phx.gbl...

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

[Nicole Calinoiu]

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" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:u9**************@TK2MSFTNGP14.phx.gbl...

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

[Nicole Calinoiu]

Sorry, weird copy-paste artifact. That should have been:

IStackWalk perm = new
SecurityPermission(SecurityPermissionFlag.Unmanage dCode);
perm.Assert();
....
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:u9**************@TK2MSFTNGP14.phx.gbl...

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 Walsh]

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" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:u9**************@TK2MSFTNGP14.phx.gbl...

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

[Richard Blewett [DevelopMentor]]

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();
}

[Michel Walsh]

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

"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:eB*************@TK2MSFTNGP10.phx.gbl...

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();
}

[Nicole Calinoiu]

"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:Os**************@TK2MSFTNGP11.phx.gbl...

Hi Nicole,
That is here that you hide yourself in these days... :-)
Yeah, it's been quite some time since I used that "other" product for
anything other than support of old apps that just won't die... <g>

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.
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
<g>), just give a private shout...


Thanks again, and to Nicholas too.

Vanderghast, Access MVP

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

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" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:u9**************@TK2MSFTNGP14.phx.gbl...

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

[Nicole Calinoiu]

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).
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:eB*************@TK2MSFTNGP10.phx.gbl...

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();
}

[Richard Blewett [DevelopMentor]]

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).

[Nicole Calinoiu]

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.


"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:eP**************@TK2MSFTNGP12.phx.gbl...

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).