Comment puis-je utiliser CAS dans .NET 4 pour verrouiller mes extensions MEF?

J'ai une application dans .NET 4 qui utilise MEF pour l'extensibilité. Mon application principale a trois assemblées: Host, Application et Contracts.Comment puis-je utiliser CAS dans .NET 4 pour verrouiller mes extensions MEF?

Host est l'exécutable "boot-strapping" qui crée le conteneur et effectue la composition.

Application contient la logique de mon application, et plus de points d'extension pour des tiers.

Contracts contient les interfaces (et certaines classes auxiliaires) utilisées dans les points d'extension. Par conséquent, une personne développant une application tierce doit inclure une référence à Contracts, mais pas à Application.

Je pense que mon modèle de sécurité devrait ressembler à ceci:

Host et Application devrait être SecurityCritical
Contracts devrait être SecuritySafeCritical
Toutes les extensions 3ème partie doivent être SecurityTransparent

Je pense que 1. sera satisfait par défaut. Je sais que je peux implémenter 2. avec un attribut d'assemblage. La question est, comment puis-je appliquer la règle 3.? Est-ce que le système d'exploitation le fait automatiquement en signalant que toutes les extensions téléchargées ne sont pas fiables? Est-il possible qu'un assembly d'extension téléchargé devienne entièrement fiable?

Source

2010-08-04 Scott Whitlock

Vous demandez: « Est-il possible pour un ensemble d'extension pour devenir pleinement téléchargé confiance? » Cela peut dépendre de la façon dont les extensions sont téléchargées. Si un utilisateur peut télécharger manuellement un assembly, puis cliquez avec le bouton droit sur Propriétés et choisissez "Débloquer", il regarde le système comme un assembly local. – JaredReisinger

@JaredReisinger: Cela a du sens. Je suppose que les tierces parties peuvent également signer des assemblées, mais je suis confus quant au processus. –

Si votre application fonctionne en toute confiance, alors vos extensions fonctionneront en toute confiance et pourront faire tout ce qu'elles veulent. Peu importe les attributs de sécurité sur eux. Pour limiter ce que les extensions peuvent faire, vous devez créer un domaine d'application sandbox. Vous devez définir votre Host et Application en tant que confiance totale en ce que AppDomain et tout autre code aurait seulement les autorisations que vous lui accordez.

Voici un article MSDN sur ce sujet: How to: Run Partially Trusted Code in a Sandbox

Source

2010-08-04 06:04:42

Je pense que c'est une cause perdue. Toute personne qui écrit une extension tierce et l'empaquette dans un fichier d'installation et demande au propriétaire du PC d'exécuter le fichier d'installation pourra exécuter son code en toute confiance. MEF ne vous permet pas de charger des assemblys d'extension dans leur propre domaine d'application. Peut-être que je peux charger mon code très critique (contenant des clés de sécurité, etc.) dans * son * propre domaine d'application. –

@Scott Vous pouvez concevoir votre application de telle sorte que les extensions tierces soient un package que votre application comprend à la place des fichiers d'installation exécutables. Ensuite, vous avez votre application gérer les extensions et ne pas le laisser exécuter du code sur l'installation. MEF ne fait rien de spécifique avec AppDomains, mais vous pouvez toujours créer un AppDomain en bac à sable, puis créer un conteneur MEF dans ce AppDomain. Ou vous pouvez regarder System.Addin (MAF), qui gère la création de plugins dans différents AppDomains.MAF est assez compliqué, donc il pourrait être plus facile de rouler votre propre sandboxing avec MEF. –

Comment puis-je utiliser CAS dans .NET 4 pour verrouiller mes extensions MEF?

Répondre

Questions connexes