2009-05-15 1 views
5

Per firmare un assembly A è necessario assicurarsi che tutti gli assembly B, C, D utilizzati da A siano firmati e quindi tutti gli assembly utilizzati da B, C, D e così via. Non capisco qual è il vantaggio in termini di sicurezza di questo. Penso che dovrebbe impedire la manomissione, ma l'assemblea A può aprire qualsiasi file e questi possono essere manomessi. Lo stesso vale per un server web esterno.Perché non è possibile che gli assembly con nome elevato utilizzino assiemi non firmati?

Inoltre, è troppo facile firmare un assembly con un file .snk reso pubblico, eludendo il requisito.

+3

"è troppo facile firmare un assembly con un file .snk che rendere pubblico ": Quindi non rendere pubblico il tuo file snk ... –

+0

Intendevo dire che si trattava di una soluzione al requisito di transitività. Il mio punto è che non è abbastanza facile; non avere il requisito di transitività sarebbe più facile e equivale alla stessa cosa. –

+1

Eric Lippert ha scritto di recente su questo blog: http://blogs.msdn.com/ericlippert/archive/2009/06/04/alas-smith-and-jones.aspx –

risposta

2

Un altro motivo per la denominazione forte è il controllo delle versioni. Se fai riferimento a un assembly con nome forte, ottieni quella versione specifica e caricherà le sue dipendenze dalle versioni specifiche su cui si basa.

EDIT

Scenario di esempio: Se si mette un assembly nella Global Assembly Cache, deve essere forte di nome per consentire side-by-side delle versioni. Tuttavia, non è possibile inserirlo nel GAC, a meno che non esistessero anche le sue dipendenze (altrimenti non sarebbero in grado di caricare in fase di esecuzione). Affinché questi assembly possano essere caricati in modo affidabile, devono essere chiamati anche in modo sicuro e nel GAC.

+0

Sì. Sono d'accordo che ci sono benefici per un nome forte. Quello che non vedo è il beneficio del requisito di transitività. –

1

È perché l'assembly con un nome elevato implica che è affidabile e i livelli di sicurezza concessi si basano sull'idea che il codice provenga da una fonte legittima. Ciò significa che anche tutti gli altri elementi con cui interagisce devono essere considerati affidabili, poiché vengono eseguiti nello stesso contesto di sicurezza.

Se gli oggetti con un nome fortemente non funzionavano in questo modo, un metodo di attacco sarebbe quello di sostituire gli elementi che non sono firmati con il codice canaglia che l'attaccante desidera eseguire. Il codice errato verrebbe eseguito nel contesto di sicurezza fidata dell'oggetto firmato.

+0

È possibile sovrascrivere l'assemblaggio di file normali A dipende da, o server Web falsi a cui si connette. Forse A costruisce codice di runtime da queste fonti e il rischio per la sicurezza è lo stesso. È la chiamata A per utilizzare gli assembly non firmati e aprirsi per attaccare. Nota che A può già farlo: basta firmare B con una chiave e renderla pubblica. È solo scomodo. –

8

Il punto è che altrimenti si potrebbe sostituire l'assemblaggio B/C/D con uno diverso (hackerato), e A non lo noterebbe mai; li caricherà ed eseguirà il codice. Con una denominazione forte, non è possibile eseguire questa operazione senza la nuova firma del B/C/D compromesso con la stessa chiave o hackerando A.

+0

Non sarebbe possibile sostituire B/C/D se sono stati firmati, solo se non lo fossero. È la chiamata di A. –

+0

@Bruno - questo è il mio punto ... –

+0

Ma non è così che funziona ora. A non può decidere se dipendere da B/C/D firmato o non firmato. Devono essere firmati perché A è. –