Re: Custom security permission exception error message

From: Nicole Calinoiu (calinoiu)
Date: 10/07/05 

Date: Fri, 7 Oct 2005 10:14:03 -0400

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

Relevant Pages

  • Re: Custom security permission exception error message
    ... We have decided against the APTCA route. ... Using TLBIMP we have strong named our dependent assemblies ... > unrestricted permission grant. ...
    (microsoft.public.dotnet.security)
  • Re: Reason behind implicit FullTrust LinkDemand?
    ... - ensuring correctness of all system assemblies doesn't solve problem as ... - APTCA flag allows distinguishing more dangerous assemblies from these that ... This allows building corporate security policy ... The removal of permissions from the Internet Zone or the ...
    (microsoft.public.dotnet.security)
  • Re: strong name and web service
    ... Great, that solves one question, strong name won't be checked by clients. ... I am investigating the use of strong naming in our .Net solutions. ... What can I benefit from strong naming a web service? ... > You can assign a strong name to assemblies that make up a web service, ...
    (microsoft.public.dotnet.security)
  • Re: strong naming?
    ... Lack of strong naming means the runtime only has a version and path to load. ... There may be cached assemblies, ... reference different "versions" of the dll. ...
    (microsoft.public.dotnet.framework)
  • RE: ASP.Net 1.1 shadow copy + reflection problem
    ... Well if you use strong naming the problem will not dissapear but rather ... If you load all your dll's from the same folder you can simplify this by ... > (assemblies) from other directories that are not the bin. ...
    (microsoft.public.dotnet.framework)