vrijdag, juli 13, 2007

Microsoft .NET 2.0 Code Access Security (3)

OK, zoals je in de twee voorgaande blogs kan nalezen: ik wilde in mijn ASP.NET website een client-side .NET user control toegang geven tot het lokale bestandssysteem. Voor het gemak wilde ik deze assembly dus Full Trust geven. Ik kon daar geen gebruikersvriendelijke manier voor vinden.

De manieren die ik heb op kunnen maken uit de geraadpleegde bronnen om een assembly Full Trust te geven:
  1. Via de .NET Framework 2.0 Configuration MMC snap-in (mscorcfg.msc);
  2. Via het uitvoeren van een specifieke caspol.exe opdrachtregel;
  3. Via het uitvoeren van een mooi voorbereid Windows Installer Package .MSI bestand;
  4. Via het direct toevoegen van je permission rule aan het configuratiebestand security.config.

Ik heb ze allevier uitgeprobeerd.

1. MMC snap-in ---

De MMC snap-in werkt mbv wizards. Dat is wel zo prettig. Twee wizards zijn hier relevant:

  1. Increase Assembly Trust;
  2. Create Deployment Package.

Ad 1. Geef hier rechtstreeks de url op van de assembly die je Full Trust wilt toekennen. Blijkt dat je assembly wel strongly signed moet zijn! Logisch ook, anders kan iedere willekeurige assembly op van die lokatie wordt gedownload per ongeluk Full Trust krijgen.

Ad 2. Middels de MMC snap-in is dit de enige manier om settings te exporteren en op een andere computer te importeren. Deze wizard genereert een MSI met daarin de volledige security.config. Niet echt heel handig want je wilt specifiek maar één instelling wijzigen.

Het lompe van de MMC snap-in is dat je niet echt inzicht krijgt in waar de wizard precies zijn instellingen heeft weggeschreven. Daaraan toegevoegd het feit dat je gewoon keer op keer opnieuw je assembly FullTrust kan geven. De MMC snap-in helpt je dus niet echt in het vergaren van inzicht.

2. Caspol ---

Ik ging kijken naar caspol.exe. Ik voerde caspol.exe -m -af uit. Caspol zei netjes "Success". Bij de tweede keer uitvoeren de melding: ERROR: This assembly is already fully trusted.

Blijkt echter dat IEHost zich weinig aantrekt van deze status. IEHost genereert nog steeds een exception. Klaarblijkelijk zag ik hier iets over het hoofd. Caspol is dus ook niet een tool die een beginner echt op weg helpt.

3. MSI ---

Ik heb nog even vluchtig gekeken of ik een eenvoudige MSI kon genereren met één instelling erin. Ik heb een aantal MSI unpackers geprobeerd, maar na een paar pogingen begon ik me te realiseren dat MSI eigenlijk een vrij obscuur "database" formaat is waar ik misschien maar niet te veel tijd in moest steken.

4. Security.config ---

En dan komen we eindelijk uit waar ik wezen wilde, inzicht! Security.config is zoals alle config-files binnen het .NET framework xml-gestructureerd.

Ik gok erop dat er op drie niveaus een security.config leeft:

  1. Enterprise;
  2. Machine;
  3. User.

Ik richt me nu even op het machine-niveau, maar ik neem aan dat het volgende inzicht ook van toepassing is op het user-niveau.

Security.config blijkt te bestaan uit vier blokken gekenmerkt door de volgende elementen:

  1. SecurityClasses; hierin staan .NET classes verantwoordelijk voor het interpreteren van verdere xml data in het bestand;
  2. NamedPermissionSets; een reeks PermissionSets waaronder de PermissionSet "FullTrust";
  3. geneste CodeGroup elementen, waaronder de door de MMC snap-in wizard gegenereerde codegroup "Wizard_0" met omschrijving "Codegroup generated by the .NET Configurationtool";
  4. FullTrustAssemblies; een hele lijst assemblies met fully trusted status.

Caspol blijkt de drie laatste blokken netjes te kunnen listen:

  1. Caspol -lp; list permissionsets;
  2. Caspol -ld; list codegroups met descriptions;
  3. Caspol -lf; list fully trusted assemblies.

Standaard opereert caspol op het niveau van de machine.

Ik keek naar de codegroup die door de snapin wizard was toegevoegd:

<codegroup class="UnionCodeGroup" description="Codegroup generated by the .NET Configuration tool" version="1" permissionsetname="FullTrust" attributes="LevelFinal" name="Wizard_0">

<imembershipcondition class="StrongNameMembershipCondition" version="1" name="Upload" publickeyblob="ABC..." assemblyversion="1.0.2749.38494">

</codegroup>

En jawel! De puzzelstukjes vielen in elkaar: Een assembly met naam Upload met publickey ABC... en versie 1.0.2749.38494 wordt door het systeem gezien als member van de permissionset FullTrust. En dat wilden we bereiken!

Maar goed, leuk al dat inzicht maar dat brengt me nog niets verder. Ik heb nog steeds geen gebruikersvriendelijke manier om de gewenste permissies te vragen.

Misschien naar .NET ClickOnce kijken? Ik gok erop dat dit niet werkt in combinatie met ASP.NET. ClickOnce richt zich op geïsoleerde Windows Forms applicaties die direct kunnen worden gestart door te klikken op een link à la Java Web Start van Sun.

Is het mogelijk om een MSI te bakken die maar één codegroup toevoegt aan security.config?

In de tussentijd plaats ik op mijn website maar een batchfile met daarin een caspol-opdracht...

Of toch met SilverLight aan de slag?

Geen opmerkingen: