Asserting the permission to execute unmanaged code

[Michel Walsh]

Hi,
What is the "declaratio n" (class) I need to assert the permission that
my code can run unmanaged code.

I have:
=============== =
[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eCounter( ref long

lpPerformanceCo unt);

[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eFrequency( ref long

lpFrequency);

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

and before calling QueryPerformanc eCounter, 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

CodeAccessPermi ssion perm = new SecurityAction? ?? ; // <<< HERE

perm.Assert();

dummy=QueryPerf ormanceFrequenc y( ref frequency);

dummy=QueryPerf ormanceCounter( ref fpsStartingCoun ter);

perm.RevertAsse rt();

....

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

Thanks in advance,

Vanderghast, Access MVP

[Nicholas Paldino [.NET/C# MVP]]

Michel,

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

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:u9******** ******@TK2MSFTN GP14.phx.gbl...

Hi,
What is the "declaratio n" (class) I need to assert the permission that
my code can run unmanaged code.

I have:
=============== =
[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eCounter( ref long

lpPerformanceCo unt);

[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eFrequency( ref long

lpFrequency);

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

and before calling QueryPerformanc eCounter, 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

CodeAccessPermi ssion perm = new SecurityAction? ?? ; // <<< HERE

perm.Assert();

dummy=QueryPerf ormanceFrequenc y( ref frequency);

dummy=QueryPerf ormanceCounter( ref fpsStartingCoun ter);

perm.RevertAsse rt();

...

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

Thanks in advance,

Vanderghast, Access MVP

[Nicole Calinoiu]

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

IStackWalk perm = new SecurityPermiss ion
SecurityPermiss ionFlag.Unmanag edCode);
perm.Assert();

try
{
dummy = QueryPerformanc eFrequency(ref frequency);
dummy = QueryPerformanc eCounter(ref fpsStartingCoun ter);
}
finally
{
CodeAccessPermi ssion.RevertAll ();
}
"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:u9******** ******@TK2MSFTN GP14.phx.gbl...

Hi,
What is the "declaratio n" (class) I need to assert the permission that
my code can run unmanaged code.

I have:
=============== =
[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eCounter( ref long

lpPerformanceCo unt);

[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eFrequency( ref long

lpFrequency);

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

and before calling QueryPerformanc eCounter, 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

CodeAccessPermi ssion perm = new SecurityAction? ?? ; // <<< HERE

perm.Assert();

dummy=QueryPerf ormanceFrequenc y( ref frequency);

dummy=QueryPerf ormanceCounter( ref fpsStartingCoun ter);

perm.RevertAsse rt();

...

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

Thanks in advance,

Vanderghast, Access MVP

[Nicole Calinoiu]

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

IStackWalk perm = new
SecurityPermiss ion(SecurityPer missionFlag.Unm anagedCode);
perm.Assert();
....
"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:u9******** ******@TK2MSFTN GP14.phx.gbl...

Hi,
What is the "declaratio n" (class) I need to assert the permission that
my code can run unmanaged code.

I have:
=============== =
[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eCounter( ref long

lpPerformanceCo unt);

[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eFrequency( ref long

lpFrequency);

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

and before calling QueryPerformanc eCounter, 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

CodeAccessPermi ssion perm = new SecurityAction? ?? ; // <<< HERE

perm.Assert();

dummy=QueryPerf ormanceFrequenc y( ref frequency);

dummy=QueryPerf ormanceCounter( ref fpsStartingCoun ter);

perm.RevertAsse rt();

...

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

Thanks in advance,

Vanderghast, Access MVP

[Michel Walsh]

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

When I compared with FileIOPermissio n, which takes two arguments,
the first argument allowing to Append permissions as example, the fact that
SecurityPermiss ion 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 "Profession al 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******** ********@TK2MSF TNGP15.phx.gbl. ..

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

IStackWalk perm = new SecurityPermiss ion
SecurityPermiss ionFlag.Unmanag edCode);
perm.Assert();

try
{
dummy = QueryPerformanc eFrequency(ref frequency);
dummy = QueryPerformanc eCounter(ref fpsStartingCoun ter);
}
finally
{
CodeAccessPermi ssion.RevertAll ();
}
"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:u9******** ******@TK2MSFTN GP14.phx.gbl...

Hi,
What is the "declaratio n" (class) I need to assert the permission that
my code can run unmanaged code.

I have:
=============== =
[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eCounter( ref long

lpPerformanceCo unt);

[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eFrequency( ref long

lpFrequency);

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

and before calling QueryPerformanc eCounter, 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

CodeAccessPermi ssion perm = new SecurityAction? ?? ; // <<< HERE

perm.Assert();

dummy=QueryPerf ormanceFrequenc y( ref frequency);

dummy=QueryPerf ormanceCounter( ref fpsStartingCoun ter);

perm.RevertAsse rt();

...

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

Thanks in advance,

Vanderghast, Access MVP

[Richard Blewett [DevelopMentor]]

You could also put the two calls into their own internal class and apply the

[SuppressUnmanag edCodeSecurity]

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 SecurityPermiss ion
SecurityPermiss ionFlag.Unmanag edCode);
perm.Assert();

try
{
dummy = QueryPerformanc eFrequency(ref frequency);
dummy = QueryPerformanc eCounter(ref fpsStartingCoun ter);
}
finally
{
CodeAccessPermi ssion.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******@devel op.com> wrote in message
news:eB******** *****@TK2MSFTNG P10.phx.gbl...

You could also put the two calls into their own internal class and apply
the

[SuppressUnmanag edCodeSecurity]

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 SecurityPermiss ion
SecurityPermiss ionFlag.Unmanag edCode);
perm.Assert();

try
{
dummy = QueryPerformanc eFrequency(ref frequency);
dummy = QueryPerformanc eCounter(ref fpsStartingCoun ter);
}
finally
{
CodeAccessPermi ssion.RevertAll ();
}

[Nicole Calinoiu]

"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:Os******** ******@TK2MSFTN GP11.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 FileIOPermissio n, which takes two arguments,
the first argument allowing to Append permissions as example, the fact
that SecurityPermiss ion 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 "Profession al C#" (Wrox, first edition), and,
sure, the help file.
Last time I went book shopping, "Programmin g .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******** ********@TK2MSF TNGP15.phx.gbl. ..

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

IStackWalk perm = new SecurityPermiss ion
SecurityPermiss ionFlag.Unmanag edCode);
perm.Assert();

try
{
dummy = QueryPerformanc eFrequency(ref frequency);
dummy = QueryPerformanc eCounter(ref fpsStartingCoun ter);
}
finally
{
CodeAccessPermi ssion.RevertAll ();
}
"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:u9******** ******@TK2MSFTN GP14.phx.gbl...

Hi,
What is the "declaratio n" (class) I need to assert the permission
that my code can run unmanaged code.

I have:
=============== =
[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eCounter( ref long

lpPerformanceCo unt);

[System.Runtime. InteropServices .DllImport("KER NEL32")]

private static extern bool QueryPerformanc eFrequency( ref long

lpFrequency);

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

and before calling QueryPerformanc eCounter, 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

CodeAccessPermi ssion perm = new SecurityAction? ?? ; // <<< HERE

perm.Assert();

dummy=QueryPerf ormanceFrequenc y( ref frequency);

dummy=QueryPerf ormanceCounter( ref fpsStartingCoun ter);

perm.RevertAsse rt();

...

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

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******@devel op.com> wrote in message
news:eB******** *****@TK2MSFTNG P10.phx.gbl...

You could also put the two calls into their own internal class and apply
the

[SuppressUnmanag edCodeSecurity]

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 SecurityPermiss ion
SecurityPermiss ionFlag.Unmanag edCode);
perm.Assert();

try
{
dummy = QueryPerformanc eFrequency(ref frequency);
dummy = QueryPerformanc eCounter(ref fpsStartingCoun ter);
}
finally
{
CodeAccessPermi ssion.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).