web-dev-qa-db-fra.com

La tentative de la méthode transparente de sécurité X pour accéder à la méthode critique de sécurité Y a échoué

J'ai une version d'application serveur assez stable déployée depuis près d'un an chez des dizaines de clients.

Un nouveau client a récemment installé l'application et obtient l'erreur suivante:

System.MethodAccessException: la tentative d'accès à la méthode critique de sécurité [SomeOtherMethod] Par la méthode transparente à la sécurité [SomeMethod] a échoué.

SomeMethod et SomeOtherMethod sont des méthodes des assemblys que j'ai écrits, construits sur .NET 4 et qui s'exécutent dans un service Windows. Si cela fait une différence, SomeOtherMethod fait référence à un type provenant d'un assemblage tiers (EntLib 4.1) construit sur .NET 2.0. En regardant le code pour EntLib 4.1, je constate qu’ils utilisent à la fois les attributs SecurityTransparent et APTC, mais cela n’a jamais posé problème à d’autres clients.

Ces assemblys ont été mis à niveau à partir du .NET 2.0 CLR, mais il y a longtemps. Ce code exact fonctionne correctement sur d'autres clients, et je n'utilise pas explicitement l'attribut APTC, ni l'attribut SecurityCritical nulle part.

Cela m'amène à conclure qu'il s'agit d'un problème de configuration ou peut-être d'un problème de correctif .NET Framework. Y at-il eu un correctif publié pour .NET qui provoquerait ce changement radical? Existe-t-il un paramètre de configuration qui impose ce type de vérification qui est désactivé par défaut mais que mon client a peut-être activé?

Un dernier point. Mon service utilise les RDLC SSRS pour générer des PDF. En raison de certains changements dans .NET 4, je dois obliger le service à utiliser la stratégie de sécurité existante via la configuration suivante:

  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true" />
  </runtime>

Pour plus de détails sur les raisons pour lesquelles je dois procéder, consultez cet article stackoverflow: Utilisation très élevée de la mémoire dans .NET 4.0

Le point important est que je le fais également à tous mes autres clients. Seul ce client a des problèmes.

security.net-4.0cascode-access-security
21
RMD

Sigh, les modèles et les pratiques utilisés par l'équipe Microsoft Patterns and Practices responsable des bibliothèques Enterprise sont assez déplorables. Eh bien, l'exception est exacte, vous ne pouvez pas appeler une méthode portant la mention "Je vérifierai certainement la sécurité" à partir du code portant la mention "Meh, je ne vérifierai pas la sécurité, alors ne vous embêtez pas de brûler les cycles de l'unité centrale pour la vérifier". . Les échelles sont à peu près égales aux spécifications d’exception utilisées en Java. CAS est extrêmement utile, mais diagnostiquer les exceptions est un casse-tête majeur et implique souvent un code que vous ne possédez pas et que vous ne pouvez pas réparer. Grande raison pour laquelle il est devenu obsolète dans .NET 4.

Éditorial terminé. Pour résoudre ce problème, il faut savoir pourquoi la CAS est appliquée ici. L'explication la plus simple à cela est que le service ne fonctionne pas en toute confiance. L'explication la plus simple de que est que le client n'a pas installé le service sur le disque dur local. Ou exécute généralement du code en mode "ne faites pas confiance", même dans les assemblys locaux, un administrateur très paranoïaque pourrait préférer cela. Cela doit être configuré avec Caspol.exe, un outil dont les options de ligne de commande sont aussi mystérieuses que CAS. Tir au pot à l'explication d'emplacement non approuvé, votre client doit exécuter Caspol comme indiqué dans cet article blog . Ou simplement, déployez simplement le service localement pour que la valeur par défaut "Je te fais confiance" soit appliquée.

Modification dans le motif réel tel que découvert par l'OP: méfiez-vous du flux de données alternatif qui est ajouté à un fichier lorsqu'il est téléchargé depuis un site Internet ou réseau non approuvé. Le fichier obtiendra un flux nommé "Zone.Identifier" qui gardera une trace de son origine avec la valeur "ZoneId". C'est cette valeur qui annule la confiance dérivée de l'emplacement de stockage. Le mettant habituellement dans la zone Internet. Utilisez l'explorateur, cliquez-droit sur le fichier et cliquez sur "Débloquer" pour supprimer ce flux. Une fois que vous êtes sûr de pouvoir faire confiance au fichier :)

22
Hans Passant

Si cela aide les autres, je publie ma solution à ce problème:

1) Sur le fichier AssemblyInfo.cs, supprimez/commentez la ligne [Assembly: SecurityTransparent].

2) La classe et la méthode qui effectue le travail réel ont été marquées comme [SecuritySafeCritical], dans mon cas, en établissant une connexion réseau:

[SecuritySafeCritical]
public class NetworkConnection : IDisposable
{
    [SecuritySafeCritical]
    public NetworkConnection(string networkName, NetworkCredential credentials)
    {
        .............
    }
}

3) La classe et la méthode de l'appelant étaient commercialisées comme [SecurityCritical]:

[SecurityCritical]
public class DBF_DAO : AbstractDAO
{
    [SecurityCritical]
    public bool DBF_EsAccesoExclusivo(string pTabla, ref ArrayList exepciones)
    {
        ....
        using (new NetworkConnection(DBF_PATH, readCredentials))
        {
            ....
        }
    }
}
10
Jhollman

Je faisais face au même problème en exécutant l'exemple de WCF téléchargé depuis http://www.idesign.net/ en utilisant leur bibliothèque ServiceModelEx. J'ai commenté la ligne ci-dessous dans AssemblyInfo.cs dans ServiceModelEx. projet

//[Assembly: AllowPartiallyTrustedCallers]

et cela a fonctionné pour moi.

9
Hemendr

Dans mon cas, c’était un problème lorsque j'ai géré un package NuGet dans la solution, certains packages remplaçant la liaison de version System.Web.Mvc Assembly dans le projet de site Web principal. Réglez à 4.0.0.0 (j'avais 5.0 installé). Je n'ai pas changé d'avis, car Mvc v4.0 était installé et accessible via GAC. Reculer

0
wałdis iljuczonok