[.NET] StrongNameIdentityPersmission

[whoami]

Naar aanleiding van dit topic, ben ik gisteravond eens gaan spelen met strong naming icm StrongNameIdentityPermission.

Wat ik dus wou bereiken, is dat m'n assembly B enkel mocht 'gecalled' worden, door assemblies die m'n public key kennen.

Wat ik dus gedaan heb:

1) een private en een public key bekomen dmv de sn.exe tool.
2) m'n Assembly B gesigned met deze key, dmv het AssemblyKeyFile attribute te gebruiken in de AssemblyInfo.cs
3) Een class in m'n Assembly B het StrongNameIdentityPermission Attribute gegeven:

code:

[StrongNameIdentityPermission (SecurityAction.Demand)]
public class MyClass
{
}

4) M'n assembly A heeft een reference naar assembly B, en assembly A heeft geen strong name (is dus niet gesigned).
Als ik in assembly A een object van MyClass (die in assembly B zit) wou instantieren, dan kreeg ik gisteren een Exception \o/ Woei, want dat was ook de bedoeling.
Als ik assembly A sign met dezelfde key als assembly B, dan werkt het wel. Wederom woei.

Echter, nu ik ditzelfde eens wou doen in een van m'n projectjes, dan wil het opeens niet meer lukken ?
Ik sign m'n classlibrary met diezelfde public key die ik gisteren had gegenereerd; ik geef een StrongNameIdentityPermission aan één van m'n classes in die assembly, en m'n applicatie die deze classlibrary gebruikt, sign ik niet.
Toch kan ik vanuit dat programma die class instantieren Waarom krijg ik hier nu geen exception op ? Wat doe ik verkeerd ?

Wat ik ook niet helemaal snap is hetvolgende:
Volgens de MSDN zou het 'StrongNameIdentityPermission' attribute 2 argumenten moeten nemen, nl. een SecurityAction en de public key.
Echter, in werkelijkheid neemt hij slechts 1 argument, nl. de SecurityAction.
Hoe gaat die 'gecallede' assembly dan weten welke public key de 'aanroepende' assembly moet kennen om het gebruik van die class toe te laten ?
Gaat dit dan dmv de key waarmee de 'gecallede' assembly gesigned is ?

[ Voor 5% gewijzigd door whoami op 20-03-2005 10:56 ]

[whoami]

whoami schreef op zondag 20 maart 2005 @ 10:56:
Wat ik ook niet helemaal snap is hetvolgende:
Volgens de MSDN zou het 'StrongNameIdentityPermission' attribute 2 argumenten moeten nemen, nl. een SecurityAction en de public key.
Echter, in werkelijkheid neemt hij slechts 1 argument, nl. de SecurityAction.
Hoe gaat die 'gecallede' assembly dan weten welke public key de 'aanroepende' assembly moet kennen om het gebruik van die class toe te laten ?
Gaat dit dan dmv de key waarmee de 'gecallede' assembly gesigned is ?

Ok , hier had ik verkeerd gekeken (nuja)...

Het is wel mogelijk om de publicKey mee te geven, maar dan moet je 't zo doen:

code:

[StrongNameIdentityPermission(SecurityAction.Demand, PublicKey = "....")]

Nu heb een voorbeeldje opnieuw werkend gekregen (althans, gedeeltelijk )
Ik heb een classlib gemaakt, deze een strong name gegeven, de public key uit m'n key-file ge-extracted, en een class in deze classlib met het strongnameidentitypermission attribute gedecoreert, en de public key bepaalt.
Als ik deze class nu aanroep vanuit een winform applicatie, dan krijg ik -zoals verwacht- de security-exception.

Echter, als ik nu m'n winforms applicatie met dezelfde keyfile sign, en ik roep de class aan, dan krijg ik nog altijd de security exception Dat zou nu toch niet mogen ?

[whoami]

Vreemd, m'n test-code ziet er zo uit:

code:

private void button1_Click(object sender, System.EventArgs e)
{
   MyClass c = new MyClass();       
    MessageBox.Show (c.SayName());
}

Hier krijg ik dus de security exception op de regel waar ik een instantie van MyClass instantieer.
MyClass heeft het strongnameidentitypermission attribute:

code:

[StrongNameIdentityPermission(SecurityAction.Demand,                          
                                           PublicKey = "00245.....")]
public class MyClass
{
    public MyClass()
    {
        //
        // TODO: Add constructor logic here
        //
    }
        
    public string SayName()
    {
        return "whoami";
    }
}

_{Note: beide assemblies zijn in dit geval dus met dezelfde key gesigned.}

Echter, als ik nu de code van m'n 'calling' assembly wijzig zodat het er zo uit ziet:

code:

private MyClass _c = new MyClass();

private void button1_Click(object sender, System.EventArgs e)
{
    MessageBox.Show (_c.SayName());
}

Dan laadt mijn form gewoon; iets wat ik niet zou verwachten, want m'n object _c wordt dan al ge-assigned. Ik had verwacht dat ik daar een exception op ging krijgen.
Als ik op m'n button klik krijg ik dus pas de exception op de code die _c.SayName aanroept.
Zeer vreemd, tijdens het debuggen zie ik ook dat _c geinstantieerd wordt, dus daar treedt de exceptie dan plots niet meer op.

Ik weet wel dat SecurityAction.Demand er voor zorgt dat alle 'aanroepers' hoger in de stack m'n public key moeten kennen, dus ik vermoed dat het 'm te maken heeft met het WinForms framework.
Hoe kan ik hier nu rond werken, zodanig dat die call wel werkt ?

[whoami]

Ik kan het 'oplossen' door, in plaats van een SecurityAction.Demand, een SecurityAction.LinkDemand te definieren.
Echter, daar gaat de 'controle' in tijdens het laden (tijdens de just in time compilation). De directe aanroeper moet de permissie hebben.
Bij een SecurityAction.Demand wordt er at runtime gecontroleerd, en moeten alle aanroepers die hoger in de stack zijn, de permission hebben.

Echter, nu vraag ik me af wat de mogelijke 'tekortkomingen' zijn om een LinkDemand te specifiëren ?
(Een LinkDemand is natuurlijk wel performanter, aangezien een Demand een stack-walk nodig heeft)

[ Voor 13% gewijzigd door whoami op 20-03-2005 12:58 ]

[Gerco]

whoami schreef op zondag 20 maart 2005 @ 12:57:
Echter, nu vraag ik me af wat de mogelijke 'tekortkomingen' zijn om een LinkDemand te specifiëren ?
(Een LinkDemand is natuurlijk wel performanter, aangezien een Demand een stack-walk nodig heeft)

Ik ben er ook mee aan het spelen gegaan en heb de volgende dingen ontdekt:

1. Het is op Assembly nivo alleen mogelijk om te eisen dat de code zelf gesigned is met publickey X, wat mijns inziens nogal nutteloos is aangezien je dan dus jezelf aan het checken bent.

2. Ik heb hetzelfde probleem als whoami hierboven, met een SecurityPermission.Demand werkt niet, een LinkDemand doet het prima.

Kan iemand mij het nut doen inzien van 1. en misschien een oplossing bieden voor 2. ?

[whoami]

Kan je eens 1) iets nader toelichten ?

Voor 2) heb ik ook nog steeds niets gevonden; en ik ben er zeker van dat de schuldige zich ergens in de WinForms schuilhoudt.
Echter, een SecurityAction.Demand is ws toch niet echt aan te raden omwille van performance.
Blijkbaar maakt MS in z'n Fitch&Mater example ook gebruik van SecurityAction.LinkDemand.

[Gerco]

Toelichting op 1:

Ik heb twee projecten, MyApp.exe en MyApp.dll. Ik decoreer MyApp.dll met de attribute op Assembly level (met SecurityAction.RequestMinimum) en sign MyApp.dll met de key en MyApp.exe niet. Als ik nu MyApp.exe run, werkt het prima.

Als ik echter MyApp.dll niet sign (of sign met een andere key), dan weigert MyApp.dll dienst. Het lijkt er dus op dat die attribute op Assembly nivo alleen kijkt of de eigen assembly is gesigned met die key, maar als dat zo is, is het m.i. volkomen zinloos. Ik denk dus dat ik iets verkeerd begrijp, maar ik weet alleen niet wat.

[whoami]

Als ik het goed begrijp doe jij dit:

code:

[assembly: StrongNameIdentityPermission (SecurityAction.RequestMinimum)]

in de assemblyinfo.

Afaik zorgt dit er enkel voor dat de 'uitvoerder' minimum STrongNameIdentityPermissions moet hebben om de code te kunnen runnen.

[Gerco]

Close, but not quite. Ik doe dit (pardon my VB) in MyApp.dll:

Visual Basic .NET:

<Assembly: AssemblyKeyFile("c:\devtest\idperm\mykey.snk")> 
<Assembly: StrongNameIdentityPermission(SecurityAction.RequestMinimum, _
  PublicKey:=  "0024 ... d7af")> 

Wat ik dan in MyApp.exe doe, doet niet terzake, alles werkt, signed, unsigned maakt niet uit. Als ik echter die AssemblyKeyFile weghaal (bij beide, anderd build het niet) of de PublicKey string verander, krijg ik deze SecurityException:


Recap:

MyApp.exe	MyApp.dll	Resultaat
Signed	Signed	OK
Unsigned	Signed	OK
Signed	Unsigned	Build error
Unsigned	Unsigned	Error
Signed	Signed (diff key)	Error
Unsigned	Signed (diff key)	Error

[ Voor 40% gewijzigd door Gerco op 21-03-2005 15:53 ]

[whoami]

Dat je die exception krijgt, kan iegenlijk best logisch zijn;
Bij het laden van de assembly gaat de CLR nl. gaan kijken of je die rechten hebt voor die public-key.
Echter, de exe applicatie kent de public-key niet die je nodig hebt om die DLL te laden.
(Althans, dat is wat ik veronderstel).

[Gerco]

Dat is ook precies de bedoeling, het probleem is echter dat hij het ook gewoon nog doet als mijn .exe helemaal niet gesigned is. Dan kent hij de key toch ook niet? Of haalt hij die op 1 of andere manier uit de dll tijdens het builden?

[whoami]

Idd, dat is best vreemd.

Echter, in dat geval zal je wel een security-exception krijgen als je een class probeert te instantieren die gedefinieert is in MyApp.dll. (Alleszins wanneer deze class het StrongNameIdentityPermission attribute heeft).

[Gerco]

Wanneer ik inderdaad een class ook het attribute geef (met SecurityAction.Demand), krijg ik de verwachtte exception, maar ik wilde het op de hele assembly doen en niet op elke class apart

[whoami]

Gerco schreef op maandag 21 maart 2005 @ 23:00:
Wanneer ik inderdaad een class ook het attribute geef (met SecurityAction.Demand), krijg ik de verwachtte exception, maar ik wilde het op de hele assembly doen en niet op elke class apart

Ik weet niet of dat mogelijk is, aangezien je enkel RequestMinimum kunt zetten op assembly niveau dacht ik.