2009-02-17 15 views
12

He desarrollado una aplicación .NET 3.0, que se implementa con clickonce.¿Por qué mi aplicación .net requiere plena confianza?

Me gustaría pasar de la confianza total a la confianza parcial para facilitar la implementación.

He probado la función "Calcular permisos" en la pestaña "Seguridad" de mi proyecto en Visual Studio, y la respuesta es muy clara:

--------------------------- 
Microsoft Visual Studio 
--------------------------- 
This application requires full trust to run correctly. 

Sin embargo, no hemos sido capaces de averiguar por qué se requiere plena confianza. He tratado de cambiar la configuración de seguridad de "confianza parcial", pero la aplicación plantea una SecurityException inmediatamente después de la puesta en marcha:

System.Security.SecurityException {"Request failed.", Action= "System.Security.Permissions.SecurityAction.LinkDemand" 
    at MyNameSpace.Program.Main(String[] args) 
    at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) 
    at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args) 
    at System.Runtime.Hosting.ManifestRunner.Run(Boolean checkAptModel) 
    at System.Runtime.Hosting.ManifestRunner.ExecuteAsAssembly() 
    at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData) 
    at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext) 
    at System.Activator.CreateInstance(ActivationContext activationContext) 
    at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone() 
    at System.Threading.ThreadHelper.ThreadStart_Context(Object state) 
    at System.Threading.ExecutionContext.runTryCode(Object userData) 
    at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) 
    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) 
    at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) 
    at System.Threading.ThreadHelper.ThreadStart() 

Mi software probablemente no necesite plena confianza (que sólo se conectan a un servidor web mediante https y acceder al sistema de archivos solo cuando el usuario lo solicita, para fines de importación/exportación)

¿Cómo puedo averiguar por qué mi aplicación requiere plena confianza?

+0

¿A qué llama en su método principal? Algo que está llamando allí está causando el problema. – leppie

+0

Nada. este es el constructor principal .net predeterminado para una aplicación Winform, IE Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault (falso); Application.Run (nuevo MyForm()); y nada más. Creo que el problema ocurre antes, es decir, cuando el clr carga mi ensamblaje – Brann

Respuesta

2

Agregar el atributo requirePermission = 'false' en configSections del app.config ayuda mucho:

<sectionGroup name="system.net" type="System.Net.Configuration.NetSectionGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"> 
     <section requirePermission="false" name="defaultProxy" type="System.Net.Configuration.DefaultProxySection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> 
    </sectionGroup> 

Se hizo el truco para mí!

0

Hrm, solo una conjetura, pero ¿se está ejecutando en un recurso compartido de red? .NET parece asignar confianza en función de la ubicación desde la que se ejecuta el código. Si es desde cualquier lugar que no sea su disco duro local, entonces tendrá problemas de seguridad.

+0

, creo que está viendo mi pregunta de una manera incorrecta. Ejecutar el archivo localmente en lugar de un intercambio de redes cambiaría la zona, elevando así los permisos predeterminados. ¡No quiero que mi programa requiera ningún tipo de elevación para correr! – Brann

+0

Ahh parece que lo entendí mal, lo siento Brann –

0

Sin ver el código de su aplicación, es imposible saberlo. Hay algo que requiere plena confianza en su aplicación que podría haber pasado por alto (¿quizás una dependencia?).

+0

¿No hay una manera de imitar la lógica CLR (que es capaz de determinar que necesito plena confianza inmediatamente después de lanch)? ¿Y no es posible decirle al CLR que inicie el programa en cualquier momento, y que se generen excepciones cuando mi código requiera alguna elevación, si es que alguna vez lo hace? – Brann

1

El mensaje de excepción que le está diciendo por qué no se puede ejecutar con confianza parcial:

System.Security.Permissions.SecurityAction.LinkDemand 

Si copia y pega esto en Google, encontrará varios artículos relevantes en MSDN que podrían ayudar a descubrir por qué tu aplicación requiere plena confianza.

10

Parece que mi problema está causado por el hecho de que mi ensamblaje está fuertemente firmado.

citado de msdn

En ensamblados con nombre, un LinkDemand se aplica a todos los métodos de acceso público, propiedades y eventos en el mismo para restringir su uso a las personas que llaman de plena confianza. Para desactivar esta característica, debe aplicar AllowPartiallyTrustedCallersAttributeattribute.

estoy añadiendo el atributo necesario para mi montaje, y voy a hacerle saber cómo resultan las cosas:

[assembly:AllowPartiallyTrustedCallers] 

Actualización: He añadido el atributo de mis montajes, pero También estoy usando algunos ensambles .net.

No todos los ensamblados .net pueden ser utilizados por ensamblajes parcialmente confiables (here's a list), a saber, conjuntos WCF (es decir, Sistema.ServiceModel) no está en la lista de

Sin embargo, Microsoft afirma que es posible utilizar WCF en un entorno de confianza parcial (see here)

He tratado de eliminar todos los conjuntos que no necesite de mis referencias, no tengo AllowPartiallyTrustedCallers utilizado en todos mis montajes, y todavía estoy stucked ...

+0

Brann, debe usar las funciones de comentario y edición, en lugar de agregar repetidamente las respuestas. Recomiendo fusionar sus tres respuestas en esta única respuesta y anotar las horas de cada edición/actualización antes del contenido de esa actualización. – jrista

+0

@jrista: esas tres respuestas son diferentes (y apuntan a direcciones diferentes), así que realmente no veo cómo el hecho de que las tres hayan sido publicadas por mí es relevante ... – Brann

4

Microsoft tiene una herramienta llamada permcalc que analizan una asamblea y produce un archivo de salida xml detallada que se parece a esto:

<Type Name="MyClass"> 
<Method Sig="instance void .ctor()"> 
<Demand> 
<PermissionSet version="1" class="System.Security.PermissionSet"> 
    <IPermission version="1" class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Unrestricted="true" /> 
    <IPermission version="1" class="System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Unrestricted="true" /> 
... 
+0

permcalc no es compatible con .Net 4 – Valentin

0

Su stack-trace no muestra el tipo de permiso que se solicita.

AllowPartiallyTrustedCallers no lo ayudará en este caso. Se debe especificar en el objetivo de la llamada, p. cuando un código parcialmente confiable llama a su ensamblado de confianza. En su situación, debería examinar si su aplicación llama a ensamblajes que no tienen este atributo definido. En caso afirmativo, su aplicación deberá ejecutarse con plena confianza y no funcionará en absoluto (esto es cómo se aplica CAS y es por diseño).

De lo contrario, utilice permcalc. Le mostrará los permisos que deberían habilitarse en la configuración de seguridad del proyecto. Sin embargo, no estoy seguro de si, después de incluir todas esas permanentes, todavía tendrá "confianza parcial" o más bien confianza total con unos pocos permisos despojados. Esto se debe al hecho de que la confianza parcial es muy restrictiva (open security.config y mira los permisos habilitados), hasta donde sé WebPermission no está allí (lo cual es necesario para enviar solicitudes http), lo mismo con FileIOPermission.

+0

AllowPartiallyTrustedCallers, eso es lo que hice, pero siento que el documento msdn no está actualizado (he publicado en este hilo una contradicción entre el documento msdn y una muestra de msdn ...) – Brann

+0

La confianza parcial no es tan restrictiva como usted dice . Al usar la confianza parcial, el nivel de elevación depende de su zona, o puede personalizarse, para que pueda tener FileIOPermission si lo necesita (aunque FileDialogPermission es probablemente suficiente en la mayoría de los casos). – Brann

+0

Claro que puede personalizar los permisos, pero la confianza parcial predeterminada tiene como 6-7 de ellos (LocalIntranet un par de más). – liggett78

Cuestiones relacionadas