Custom security permission exception error message

microsoft.public.dotnet.security

27 Sep 2005 1:58 PM

Marius Groenendijk

Hello group!

We're planning to use strong naming for our app and this does indeed
work fine *if* the app has been registered for fulltrust (w/ caspol).

Trouble is if it's not *yet* fully trusted. Then, if the app starts
it bombs immediately with an *ugly* message which the average end-user
would not understand or appreciate (WTH does it mean?):

An unhandled exception of type 'System.Security.SecurityException' occurred
in ...

*or*

Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
....
Click OK to terminate the application.
Click CANCEL to debug the application.

During debugging the debugger doesn't even get as far as executing
a single line of our code - it's mscoree, on loading the app, that
issues the 'ugly' msg, right?

1) What can we do to try/catch this exception so that *we* can issue
   our own 'friendly' msg?

2) What security permissions are required in AssemblyInfo (something
   that FxCop also keeps complaining about).

3) How to ensure that once the app gets past 1) (fulltrust=OK) that
   it gets the required privileges ( unmanaged code, R/W registry
   access, R/W file io, ui, reflection )?

B.t.w. the app uses ADO.NET, JRO *and* JET

Looking forward to any replies which'll be greatly appreciated
Many thanks,
Marius.

7 Oct 2005 2:14 PM

Nicole Calinoiu

"Marius Groenendijk" <M (underscore) Groenendijk At (VeryWarm) Mail> wrote
in message news:OgCL%23t2wFHA.2132@TK2MSFTNGP15.phx.gbl...
> Hello group!
>
> We're planning to use strong naming for our app and this does indeed
> work fine *if* the app has been registered for fulltrust (w/ caspol).

It is, in fact, quite possible to use strong naming without requiring an
unrestricted permission grant (full trust). The only case in which it
becomes an issue is when code with a restricted grant attempts to call into
a strongly named assembly since a link demand for unrestricted permissions
will be automatically generated by the CLR. The resulting security
exception can be avoided by applying the
AllowPartiallyTrustedCallersAttribute (APTCA) to your library assembly.
However, if you choose to go this route, you should take care to perform an
appropriate security audit of the target library assemblies since applying
APTCA can open your code to new security risks due to the new class of
caller.

> Trouble is if it's not *yet* fully trusted. Then, if the app starts
> it bombs immediately with an *ugly* message which the average end-user
> would not understand or appreciate (WTH does it mean?):

It means that the implicit link demand for full trust generated by the CLR
failed. (And, yes, it's a horribly opaque exception message. <g>)

Show quoteHide quote

>
> An unhandled exception of type 'System.Security.SecurityException'
> occurred in ...
>
> *or*
>
> Common Language Runtime Debugging Services
> Application has generated an exception that could not be handled.
> ...
> Click OK to terminate the application.
> Click CANCEL to debug the application.
>
>
> During debugging the debugger doesn't even get as far as executing
> a single line of our code - it's mscoree, on loading the app, that
> issues the 'ugly' msg, right?
>
> 1) What can we do to try/catch this exception so that *we* can issue
> our own 'friendly' msg?

If you don't want to go the APTCA route, you'll need to ensure that you test
for an unrestricted permission grant in your launching executable (which
won't guarantee unrestricted grants across all assemblies of your
application but is at least a start) in code that runs before the JITting of
any code that uses a non-APTCA library (since link demands are tested at
JIT-time). If your own test for an unrestricted permission grant fails, you
can show whatever friendly error message you like to the user.

> 2) What security permissions are required in AssemblyInfo (something
> that FxCop also keeps complaining about).

They're not required, but they are recommended. These are attributes that
declaratively specify what permissions your assembly needs (or doesn't) in
order to run. See
http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx for a
description of how these work.

> 3) How to ensure that once the app gets past 1) (fulltrust=OK) that
> it gets the required privileges ( unmanaged code, R/W registry
> access, R/W file io, ui, reflection )?

If an assembly receives an unrestricted permission grant, it will pass a
demand for any built-in or custom CAS permission.

> B.t.w. the app uses ADO.NET, JRO *and* JET

If you're using the types from the System.Data.OleDb namespace to connect to
your Jet db, the assembly calling into those types will need to be fully
trusted since they make explicit link demands for full trust. This is
unrelated to the strong naming issue, but it does mean that at least one of
your assemblies would presumably need to be fully trusted. It also
potentially increases your audit burden should you decide to go the APTCA
route since some fairly dangerous things can be done via db calls.

Show quoteHide quote

>
> Looking forward to any replies which'll be greatly appreciated
> Many thanks,
> Marius.
>
>

10 Oct 2005 9:12 AM

Marius Groenendijk

Merci beaucoup Nicole! It's a [little] bit clearer now.

We have decided against the APTCA route.

Using TLBIMP we have strong named our dependent assemblies
(JRO & ADOX interop) using the *same* strong name as our main app.

At install time we run CASPOL to register the strong named app for
full trust. From that point onwards there seems to be no more problem
and the dependent assemblies are trusted as well and we can run just
fine from a network share or mapped drive.

If all of this works we don't have to worry about the unfriendly
security exception msg. Not fail safe but it's a start.

Thanks again,
Marius.

Show quoteHide quote

"Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
news:%23CKz9u0yFHA.1264@tk2msftngp13.phx.gbl...
> "Marius Groenendijk" <M (underscore) Groenendijk At (VeryWarm) Mail> wrote
> in message news:OgCL%23t2wFHA.2132@TK2MSFTNGP15.phx.gbl...
>> Hello group!
>>
>> We're planning to use strong naming for our app and this does indeed
>> work fine *if* the app has been registered for fulltrust (w/ caspol).
>
> It is, in fact, quite possible to use strong naming without requiring an
> unrestricted permission grant (full trust). The only case in which it
> becomes an issue is when code with a restricted grant attempts to call
> into a strongly named assembly since a link demand for unrestricted
> permissions will be automatically generated by the CLR. The resulting
> security exception can be avoided by applying the
> AllowPartiallyTrustedCallersAttribute (APTCA) to your library assembly.
> However, if you choose to go this route, you should take care to perform
> an appropriate security audit of the target library assemblies since
> applying APTCA can open your code to new security risks due to the new
> class of caller.
>
>
>
>> Trouble is if it's not *yet* fully trusted. Then, if the app starts
>> it bombs immediately with an *ugly* message which the average end-user
>> would not understand or appreciate (WTH does it mean?):
>
> It means that the implicit link demand for full trust generated by the CLR
> failed. (And, yes, it's a horribly opaque exception message. <g>)
>
>
>>
>> An unhandled exception of type 'System.Security.SecurityException'
>> occurred in ...
>>
>> *or*
>>
>> Common Language Runtime Debugging Services
>> Application has generated an exception that could not be handled.
>> ...
>> Click OK to terminate the application.
>> Click CANCEL to debug the application.
>>
>>
>> During debugging the debugger doesn't even get as far as executing
>> a single line of our code - it's mscoree, on loading the app, that
>> issues the 'ugly' msg, right?
>>
>> 1) What can we do to try/catch this exception so that *we* can issue
>>   our own 'friendly' msg?
>
> If you don't want to go the APTCA route, you'll need to ensure that you
> test for an unrestricted permission grant in your launching executable
> (which won't guarantee unrestricted grants across all assemblies of your
> application but is at least a start) in code that runs before the JITting
> of any code that uses a non-APTCA library (since link demands are tested
> at JIT-time). If your own test for an unrestricted permission grant
> fails, you can show whatever friendly error message you like to the user.
>
>
>
>> 2) What security permissions are required in AssemblyInfo (something
>>   that FxCop also keeps complaining about).
>
> They're not required, but they are recommended. These are attributes that
> declaratively specify what permissions your assembly needs (or doesn't) in
> order to run. See
> http://blogs.msdn.com/shawnfa/archive/2004/08/30/222918.aspx for a
> description of how these work.
>
>
>> 3) How to ensure that once the app gets past 1) (fulltrust=OK) that
>>   it gets the required privileges ( unmanaged code, R/W registry
>>   access, R/W file io, ui, reflection )?
>
> If an assembly receives an unrestricted permission grant, it will pass a
> demand for any built-in or custom CAS permission.
>
>
>> B.t.w. the app uses ADO.NET, JRO *and* JET
>
> If you're using the types from the System.Data.OleDb namespace to connect
> to your Jet db, the assembly calling into those types will need to be
> fully trusted since they make explicit link demands for full trust. This
> is unrelated to the strong naming issue, but it does mean that at least
> one of your assemblies would presumably need to be fully trusted. It also
> potentially increases your audit burden should you decide to go the APTCA
> route since some fairly dangerous things can be done via db calls.
>
>>
>> Looking forward to any replies which'll be greatly appreciated
>> Many thanks,
>> Marius.