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

Re: Asserting the permission to execute unmanaged code

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]
- mvp@spam.guard. caspershouse.co m

"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:u9VJtobvEH A.3320@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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
>
>
>
>[/color]

[Nicole Calinoiu]

Re: Asserting the permission to execute unmanaged code

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:u9VJtobvEH A.3320@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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
>
>
>
>[/color]

[Nicole Calinoiu]

Re: Asserting the permission to execute unmanaged code

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:u9VJtobvEH A.3320@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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
>
>
>
>[/color]

[Michel Walsh]

Re: Asserting the permission to execute unmanaged code

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:%23oNJWzbv EHA.2012@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> 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:u9VJtobvEH A.3320@TK2MSFTN GP14.phx.gbl...[color=green]
>> 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
>>
>>
>>
>>[/color]
>
>[/color]

[Richard Blewett [DevelopMentor]]

Re: Asserting the permission to execute unmanaged code

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]

Re: Asserting the permission to execute unmanaged code

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]" <richardb@devel op.com> wrote in message
news:eBrIYCcvEH A.716@TK2MSFTNG P10.phx.gbl...[color=blue]
> 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 ();
> }
>[/color]

[Nicole Calinoiu]

Re: Asserting the permission to execute unmanaged code

"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:OsgfzBcvEH A.1520@TK2MSFTN GP11.phx.gbl...[color=blue]
> Hi Nicole,
>
>
> That is here that you hide yourself in these days... :-)[/color]

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>

[color=blue]
> 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.[/color]

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

[color=blue]
>
>
>
> Thanks again, and to Nicholas too.
>
> Vanderghast, Access MVP
>
>
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:%23oNJWzbv EHA.2012@TK2MSF TNGP15.phx.gbl. ..[color=green]
>> 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:u9VJtobvEH A.3320@TK2MSFTN GP14.phx.gbl...[color=darkred]
>>> 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
>>>
>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Nicole Calinoiu]

Re: Asserting the permission to execute unmanaged code

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]" <richardb@devel op.com> wrote in message
news:eBrIYCcvEH A.716@TK2MSFTNG P10.phx.gbl...[color=blue]
> 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 ();
> }
>[/color]

[Richard Blewett [DevelopMentor]]

Re: Asserting the permission to execute unmanaged code

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]

Re: Asserting the permission to execute unmanaged code

At the time that the p/invoke methods are moved into a separate class marked
with SuppressUnmanag edCodeSecurityA ttribute, 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 SuppressUnmanag edCodeSecurityA ttribute 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]" <richardb@devel op.com> wrote in message
news:eP5Ec$fvEH A.1260@TK2MSFTN GP12.phx.gbl...[color=blue]
> 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).
>
>
>
>[/color]