Come contrassegnare un .net assembly come sicuro?

Come contrassegno come assembly “sicuro”?

In alternativa, come posso visualizzarmi Visual Studio quando qualcosa nel mio assieme non è “sicuro”?


A volte non è ansible utilizzare un assembly a meno che non sia “sicuro” (ad esempio da SQL Server ).

vorrei che il mio assemblaggio fosse contrassegnato come sicuro. Se la mia assemblea non può essere contrassegnata come sicura perché non è sicura, mi piacerebbe sapere come posso sapere che il mio assemblaggio non è sicuro.


Ci sono alcuni concetti in Visual Studio che sembrano riferirsi alla sicurezza, che può o non può avere nulla a che fare con un assembly che è “sicuro”:

  1. Consenti l’ opzione di assemblaggio del codice non sicuro :

    inserisci la descrizione dell'immagine qui

    • Cosa è permesso se controllo l’opzione Consenti codice non sicuro ?
    • Cosa non è consentito se deseleziono l’opzione Consenti codice non sicuro ?
    • Quale relazione, se esiste, ha “codice non sicuro” ha a che fare con un assembly che è “sicuro”?

      (chiedo perché il mio assembly non “consente codice non sicuro”, ma consente le chiamate P / Invoke – che pensavo fosse la definizione di “non sicuro”)

  2. Opzione di assemblaggio ClsCompliant :

    [assembly: CLSCompliant(true)] namespace MyApplication 
    • Qual è la relazione, se esiste, che il codice “cls compliant” ha a che fare con un assembly che è “sicuro”?
  3. blocco di codice non sicuro :

     int error; unsafe { error = 0x80004005; } 

    Il codice all’interno del blocco unsafe è “non sicuro”

  4. UnsafeNativeMathods

    Microsoft consiglia di creare una class denominata UnsafeNativeMethods che contiene codice gestito non sicuro:

     [SuppressUnmanagedCodeSecurity] internal static class UnsafeNativeMethods { ... } 

    Questo contrasta con SafeNativeMethods :

     [SuppressUnmanagedCodeSecurity] internal static class SafeNativeMethods { ... } 

    che contiene metodi nativi sicuri e NativeMethods :

     internal static class SafeNativeMethods { ... } 

    che contengono metodi nativi.

Come contrassegno come assembly “sicuro”?

In che modo SQL sa che l’assembly è “non sicuro”?

  • Leggendo da questo , il “Sicuro” per SQL Server è un:

SICURO è il set di autorizzazioni più restrittivo. Il codice eseguito da un assembly con autorizzazioni SAFE non può accedere a risorse di sistema esterne quali file, rete, variabili di ambiente o registro

quindi riguarda l’ authorization all’esecuzione del codice impostata all’interno del dominio del codice SQL Server

  • Unsafe flag non Unsafe di VS non ha nulla a che fare, fondamentalmente, con la sicurezza dell’esecuzione del codice, ma consente l’esecuzione di codice non gestito . Questo riguarda l’ integrazione del codice non gestito nel codice gestito

  • CLS Compilant attributo CLS Compilant come definito qui riguarda la definizione del codice dell’assieme contrassegnato con tale attributo come un codice che segue le linee guida CSL (Common Language Specification). Quindi questo sulla compilazione e l’architettura del codice .

Come contrassegno come assembly “sicuro”?

Definito nel primo collegamento in questa risposta e ha una relazione con l’integrazione di SQL Server.

In che modo SQL sa che l’assembly è “non sicuro”?

Considerando la descrizione fornita: “Crea un modulo di applicazione gestita che contiene metadati di class e codice gestito come object in un’istanza di SQL Server”, relè SQL Server sui metadata , che in alcuni campi fornisce un’informazione sul fatto se è “sicuro” o no.

Come contrassegno come assembly “sicuro”?

Stai pensando a questo nel modo sbagliato.

Qualcuno che pensi forse vuole ucciderti ti dà una bottiglia e dice “bevi questo”. Dici “è sicuro da bere?” Il ragazzo dice “leggi la bottiglia”. Tu fai. Dice “SICURO PER BERE” su di esso.

Lo bevi?

Se il liquido è sicuro da bere o meno non ha assolutamente nulla a che fare con ciò che dice l’etichetta sulla bottiglia! È perfettamente ansible mettere la benzina in una bottiglia contrassegnata con “SICURO PER BERE”.

Tu sei il tipo che consegna la bottiglia piena di liquido sospetto al server SQL e SQL Server dice “Non mi fido di nessuna etichetta che stai per mettere su questo assemblaggio”. Piuttosto, renderà l’assemblea “sicura” limitando ciò che l’assemblea può fare. Blocca le autorizzazioni su quella cosa in modo che qualsiasi tentativo da parte dell’assembly di sfruttare il server SQL comporti la sua chiusura tramite un’eccezione.

Come faccio a sapere quando qualcosa nel mio gruppo non è “sicuro”?

Prova a eseguirlo in bassa fiducia. È crashato e muore con un’eccezione di sicurezza? Se la risposta è sì, allora non era sicuro secondo quel livello di fiducia . Diversi livelli di attendibilità garantiscono diversi livelli di permessi. Il codice che installi sul tuo computer è in genere completamente affidabile, il codice che esegui dalla rete aziendale è meno affidabile, il codice che esegui da Internet non ha quasi alcuna fiducia. Il codice che si esegue in SQL Server ottiene il livello minimo di attendibilità di tutti; pensa che quasi tutto sia pericoloso.

Cosa è permesso se controllo l’opzione Consenti codice non sicuro?

È quindi ansible scrivere il codice che manipola direttamente i puntatori grezzi alla memoria in un modo che preferisce. Ciò richiede piena fiducia; non ci devono essere restrizioni sull’assemblaggio se si desidera utilizzare un codice non sicuro. Il codice non sicuro può modificare ogni bit della memoria in modalità utente nel processo.

Qual è la relazione, se esiste, che il codice “cls compliant” ha a che fare con un assembly che è “sicuro”?

Nessuna, a parte il fatto che il codice CLS non consente API che assumono tipi di puntatore non elaborati.

CLS è il sottotitolo Common Language – l’insieme di funzionalità che devono essere presenti in tutti i linguaggi .NET compatibili. In questo modo non devi chiederti “hey, se scrivo questo metodo che prende un int e restituisce una stringa in C #, posso chiamarlo da F #?” Se ti limiti a seguire le regole del CLS, sai che qualsiasi linguaggio CLS può utilizzare la tua libreria e puoi usare librerie compatibili con CLS indipendentemente dalla lingua in cui sono state scritte. Non ha assolutamente nulla a che fare con la sicurezza.

Il codice all’interno del blocco non sicuro è “non sicuro”

Il codice all’interno del blocco non sicuro può danneggiare arbitrariamente la memoria durante il processo se è scritto male. Ti facciamo contrassegnare il codice come “non sicuro” in modo che tu sappia dove concentrare i tuoi sforzi di revisione del codice. In un blocco non sicuro, tu , non il linguaggio C # , sei responsabile della sicurezza del tipo e della memoria.

Una domanda che non hai chiesto:

Cosa significa contrassegnare un assembly come “sicuro per chiamante parzialmente attendibile”?

Questa è una situazione in cui contrassegni un assembly come “sicuro”. Contrassegnando un assembly con AllowPartiallyTrustedCallerAttribute (APTCA), l’autore dell’assembly, afferma che se il codice nell’assembly viene chiamato dal codice ostile a bassa attendibilità che sta tentando di attaccare l’utente, non c’è nulla nel proprio assembly che il codice ostile a bassa affidabilità può utilizzare contro l’utente. In breve, stai dicendo che “anche se completamente fidato dall’utente, il mio codice non è un’arma che il codice malvagio può usare contro l’utente”.

Abbiamo inventato APTCA perché Peter Torr e io abbiamo scoperto che c’era un modo per i chiamanti ostili che avevano un basso livello di attendibilità per ingannare il codice JScript.NET – che era altamente affidabile per impostazione predefinita – in modo tale che il basso il codice di attendibilità potrebbe causare il codice JScript.NET per attaccare l’utente per suo conto. (Questo di solito viene chiamato “attacco di richiamo” perché il codice di bassa affidabilità “attira” il codice di alta affidabilità nel fare il suo lavoro sporco per questo.)

Come una piccola parte di un grande sforzo per garantire che questo tipo di errore non si sia verificato di nuovo, il team CLR ha introdotto APTCA. Mettendo APTCA su un assembly, stai dicendo ai tuoi utenti che stai affermando che la loro fiducia nel tuo lavoro non è abusabile dal codice di terze parti ostile. Non mettere APTCA su un assembly a meno che (1) non si intenda che l’assemblaggio venga chiamato per codice che l’utente crede possa essere ostile e (2) si è effettivamente effettuato un controllo approfondito della sicurezza.

Il nuovo modello di sicurezza basato sulla trasparenza elimina gran parte della necessità di APTCA, per fortuna.

Se APTCA non è presente su un assieme, una “richiesta di collegamento” garantisce che il codice che richiama l’assembly sia completamente affidabile. Si noti che è una richiesta di collegamento , non una richiesta completa .

SQL in questo caso sta cercando il codice che hai inserito in un blocco “non sicuro”. Ecco un puntatore MSDN alla parola chiave non sicura

http://msdn.microsoft.com/en-us/library/chfa2zb8.aspx

Dipende da cosa intendi, ma se importi un assembly (ad esempio un file .dll), esiste un’opzione “unblock” nelle proprietà di tale file .dll. Questo ti permetterà di usare la DLL come riferimento.