Sécurité des assemblies

Bonjour à tous,

Supposons que j'ai 3 assemblys A, B et C

Dans l'assembly A,  une classe Ca dont les méthodes sont :
* methA1
* methA2
* methA3

Dans l'assembly B, une classe Cb dont les méthodes sont :
* methB1
* methB2
* methB3

Dans l'assembly C, une classe Cc dont les méthodes sont :
* methC1
* methC2
* methC3

Prérequis obligatoire : Toutes les méthodes de la classe Cb (de l'assembly B) doit pouvoir appeler les méthodes de la classe Cc (de l'assembly C) et vice-versa, les méthodes et les classes doivent donc être public (pas "friendly")

Ce que je voudrais faire, c'est que depuis les méthodes de ma classe Ca (de mon assembly A (methA1, methA2, methA3)), je ne puisse par exemple :
* n'avoir accès que à la méthode methB2 de ma classe Cb de mon assembly B. Les deux autres méthodes methB1 et methB3 ne doivent pas être accessible à ma classe Ca


J'ai trouvé pas mal d'attributs de sécurité qui permettent d'empecher l'accès à certaines ressources (disques, réseaux, etc), mais pas aux méthodes...

Une idée ou une piste ?

Merci

[déplacé vers csharpfr.com, plus de chance de réponses ]

Je ne suis pas sur que ce mécanisme soit implémenté au niveau de .net. Mais si c'est le cas il faut aller voir du coté de CAS (Control Access Security).

Tiens nous au courant si tu as d'avantages d'infos, la question m'interesse.

---

Cyril - MSP - MCPD ASP.net & MCTS SQL

Salut,
Tu peux jeter un oeil sur le blog de Raptorxp.
Je ne sais pas si ça répond exactement à la question, je n'ai pas relu le topic...

http://blogs.codes-sources.com/raptorxp/archive/2006/10/22/Fonctionnement-de-Code-Access-Security.aspx

---

-Blog-

Merci

Déjà lu, mais ce n'est pas ce que je chercher apparemment

> Bidou : le message de raptorXP est sur le fonctionnement général de CAS. Il faudrais un attribuer spécifique qui prend en paramètre la publickey de ton assembly appellante. Mais là encore je suis pas sur que ca serve à quelque chose.

Sinon, peux tu nous expliquer le contexte ? es tu sur d'avoir vraiment besoin de faire ce truc tout bizarre ? on peut pas simplifier ? L'autre solution que je vois c'est de le faire "manuellement" en rajoutant un argument à ta méthode et tu lui passes une clé ... mais bof :s Où alors en fouillant au niveau du stack trace pour regarder le caller et vérifier l'assembly. Mais comment connaitre le caller de la fonction ? pour l'instant je suis pas sur que ce soit possible mis à part provoquer manuellement une exception :D

---

Cyril  - MSP - MCPD ASP.net & MCTS SQL

static void Main( string [] args)
{
      StackTrace st = new StackTrace ();

      foreach ( StackFrame frame in st.GetFrames())
      {
            MethodBase mi = frame.GetMethod();
            Console .WriteLine( "{0} - {1}.{2}" , mi, mi.DeclaringType.Assembly.GetName().Name, mi.DeclaringType);
      }
      Console .ReadLine();
}
Bon, c'est pas une méthode très propre, c'est couteux et surtout, surtout ca ne fonctionnera pas si ton assembly n'a pas les droits de reflexion (restriction CAS) (j'ai pas testé mais ca parait assez logique)

Mais je ne suis pas expert en sécurité CAS, si tu as un peu de temps, je te conseille de regarder au niveau de CAS quitte à créer ta propre sécurité si elle n'existe pas :-p

---

Cyril - MSP - MCPD ASP.net & MCTS SQL

Le contexte :

1) je donne la possibilité à mes utilisateurs finaux d'écrire certaines règles métiers de traitement sous la forme de scipt VB.net
2) Je compile et exécute à la volée ces scripts via une assembly B
3) Ces scripts ont accès à une assembly A contenant mes objets métiers (c'est nécessaire pour leur traitement)

Le souci : les utilisateurs bidouilleur ayant accès aux objets métiers peuvent faire un peu tout ce qu'il veulent dans la mesure où ils ont accès à la totalité des fonctionnalités (méthodes) de ces objets : DANGEREUX !

C'est pour cela que je veux définir quelles méthodes des mes objets métiers de mon assembly B seront dispo pour mes scripts de mon assembly A


Mes pistes pour le moment :

<StrongNameIdentityPermission(SecurityAction.LinkDemand

, Name:="NOM_DE_L'assembly_Autorisée")> _
=> permetrai de spécifier pour les méthodes l'assembly qui peut accèder à celle-ci : ne semble pas fonctionner... (vu sur [ Lien ])

Je vais tester  [ Lien ] : clé publique et utilitaire.net "sn"

Je vous tiens au courant

Si d'autres ont une piste d'ici là

Dans la famille, je cherche les trucs "impossible", ben... je voudrais yoyo

[ Lien ]
http://blog.devstone.com/aaron/archive/2006/01/22/1442.aspx

C'était appremment possible avec StrongNameIdentityPermission (voir les liens donnés dans mon post précédent), mais jusqu'au framework 1.1

Depuis le framework 2.0, ça fait 4 sites de gars de chez microsoft qui explique que si l'assembly tourne en mode "Full Trust", le StrongNameIdentityPermission n'est pas vérifié...

Certains me diront : "ben change le niveau de trust de ton assembly". Jen e peux pas, elle est généré à la volée...

Je continue à chercher, toutes les pistes restes les bienvenue...

Tu charges tes assembly dynamique dans le meme appdomain ou non ? Il ne faut pas que tu les charges dans le meme appdomain car tu dois avoir des options de sécurité au niveau d'un AppDomain, il doit meme etre possible de changer le trust level dynamiquement d'un appdomain.

Si tu ne l'as pas déjà fait, essate de regarder les options de sécurité au niveau des appdomains.

---

Cyril - MSP - MCPD ASP.net & MCTS SQL

Là tu me poses une colle  

Je ne fais rien de spécial pour ne pas le charger dans le même, je te dirai donc que oui, c'est chargé dans le même.

Je jette un oeil sur cette piste en même temps