• 03/30/2017
• 6 minuti per leggere
• • g
  • D
  • m
  • Y
  • s
  • +8

La sicurezza coinvolge tre pezzi che interagiscono: sandboxing, permessi, e applicazione. Sandboxing si riferisce alla pratica di creare domini isolati in cui alcuni codici sono trattati come completamente fidati e altri codici sono limitati ai permessi nel grant impostato per la sandbox. Il codice dell’applicazione che viene eseguito all’interno dell’insieme di permessi della sandbox è considerato trasparente; cioè, non può eseguire alcuna operazione che possa influenzare la sicurezza. L’insieme di permessi per la sandbox è determinato dalle prove (classe Evidence). L’evidenza identifica quali permessi specifici sono richiesti dalle sandbox e quali tipi di sandbox possono essere creati. L’applicazione si riferisce a permettere al codice trasparente di essere eseguito solo all’interno del suo set di permessi.

Scopo del modello di trasparenza

La trasparenza è un meccanismo di applicazione che separa il codice che gira come parte dell’applicazione dal codice che gira come parte dell’infrastruttura. La trasparenza traccia una barriera tra il codice che può fare cose privilegiate (codice critico), come chiamare il codice nativo, e il codice che non può (codice trasparente). Il codice trasparente può eseguire comandi entro i limiti del set di permessi in cui sta operando, ma non può eseguire, derivare da, o contenere codice critico.

L’obiettivo primario dell’applicazione della trasparenza è di fornire un meccanismo semplice ed efficace per isolare diversi gruppi di codice in base al privilegio. Nel contesto del modello di sandboxing, questi gruppi di privilegi sono o completamente fidati (cioè non limitati) o parzialmente fidati (cioè limitati all’insieme di permessi concessi alla sandbox).

La trasparenza è stata introdotta nel .NET Framework versione 2.0 per semplificare il modello di sicurezza, e per rendere più facile scrivere e distribuire librerie e applicazioni sicure. Il codice trasparente è usato anche in Microsoft Silverlight, per semplificare lo sviluppo di applicazioni parzialmente affidabili.

Specificare il livello di trasparenza

L’attributo SecurityRulesAttribute a livello di assembly seleziona esplicitamente le regole SecurityRuleSet che l’assembly seguirà. Le regole sono organizzate sotto un sistema di livelli numerici, dove livelli più alti significano un’applicazione più stretta delle regole di sicurezza.

I livelli sono i seguenti:

• Livello 2 (Level2) – le regole di trasparenza del .NET Framework 4.

• Livello 1 (Level1) – le regole di trasparenza del .NET Framework 2.0.

La differenza principale tra i due livelli di trasparenza è che il livello 1 non applica le regole di trasparenza per le chiamate dall’esterno dell’assembly ed è inteso solo per compatibilità.

Trasparenza livello 2

La trasparenza livello 2 è stata introdotta nel .NET Framework 4. I tre principi di questo modello sono il codice trasparente, il codice security-safe-critical e il codice security-critical.

• Il codice trasparente, indipendentemente dai permessi che gli sono concessi (inclusa la piena fiducia), può chiamare solo altro codice trasparente o codice security-safe-critical. Se il codice è parzialmente fidato, può eseguire solo azioni che sono permesse dall’insieme di permessi del dominio. Il codice trasparente non può fare quanto segue:

  • Effettuare un’operazione di Assert o di elevazione di privilegio.

  • Contiene codice non sicuro o non verificabile.

  • Chiamare direttamente codice critico.

  • Chiamare codice nativo o codice che ha l’attributo SuppressUnmanagedCodeSecurityAttribute.

  • Chiamare un membro che è protetto da un LinkDemand.

  • Ereditare da tipi critici.

    Inoltre, i metodi trasparenti non possono sovrascrivere metodi virtuali critici o implementare metodi di interfaccia critici.

• Il codice security-safe-critical è completamente affidabile ma è richiamabile dal codice trasparente. Espone una superficie limitata di codice completamente fidato. Le verifiche di correttezza e sicurezza avvengono nel codice safe-critical.

• Il codice security-critical può chiamare qualsiasi codice ed è completamente fidato, ma non può essere chiamato da codice trasparente.

Trasparenza livello 1

Il modello di trasparenza livello 1 è stato introdotto nella versione 2.0 del .NET Framework per permettere agli sviluppatori di ridurre la quantità di codice che è soggetto ad una verifica di sicurezza. Anche se il livello 1 di trasparenza era disponibile pubblicamente nella versione 2.0, è stato usato principalmente solo all’interno di Microsoft per scopi di controllo della sicurezza. Attraverso le annotazioni, gli sviluppatori sono in grado di dichiarare quali tipi e membri possono eseguire elevazioni di sicurezza e altre azioni affidabili (security-critical) e quali no (security-transparent). Il codice che è identificato come trasparente non richiede un alto grado di controllo di sicurezza. Il livello 1 di trasparenza afferma che l’applicazione della trasparenza è limitata all’interno dell’assembly. In altre parole, qualsiasi tipo pubblico o membro che è identificato come critico per la sicurezza è critico per la sicurezza solo all’interno dell’assembly. Se volete applicare la sicurezza per quei tipi e membri quando sono chiamati dall’esterno dell’assieme, dovete usare le richieste di collegamento per la piena fiducia. Se non lo fate, i tipi e i membri critici per la sicurezza visibili pubblicamente sono trattati come security-safe-critical e possono essere chiamati da codice parzialmente fidato al di fuori dell’assembly.

Il modello di trasparenza di livello 1 ha le seguenti limitazioni:

• I tipi e i membri critici per la sicurezza che sono pubblici sono accessibili da codice trasparente alla sicurezza.

• Le annotazioni di trasparenza sono applicate solo all’interno di un assembly.

• I tipi e i membri critici per la sicurezza devono usare le annotazioni di collegamento per applicare la sicurezza alle chiamate dall’esterno dell’assembly.

• Le regole di ereditarietà non sono applicate.

• Esiste il potenziale per il codice trasparente di fare cose dannose quando viene eseguito in piena fiducia.

Esecuzione della trasparenza

Le regole della trasparenza non sono applicate fino a quando la trasparenza non viene calcolata. In quel momento, viene lanciata una InvalidOperationException se una regola di trasparenza viene violata. Il tempo in cui la trasparenza viene calcolata dipende da molteplici fattori e non può essere previsto. Viene calcolata il più tardi possibile. Nel .NET Framework 4, il calcolo della trasparenza a livello di assembly avviene prima che nel .NET Framework 2.0. L’unica garanzia è che il calcolo della trasparenza avverrà nel momento in cui sarà necessario. Questo è simile a come il compilatore just-in-time (JIT) può cambiare il punto in cui un metodo viene compilato e qualsiasi errore in quel metodo viene rilevato. Il calcolo della trasparenza è invisibile se il vostro codice non ha errori di trasparenza.

Vedi anche

• Codice trasparente, livello 1
• Codice trasparente, livello 2