Codice SecurityTransparent, livello 2

La trasparenza di livello 2 è stata introdotta in .NET Framework versione 4. I tre concetti principali di questo modello sono il codice Transparent, il codice SecuritySafeCritical e il codice SecurityCritical.

• Il codice Transparent, incluso il codice in esecuzione con attendibilità totale, può chiamare solo altro codice Transparent o codice SecuritySafeCritical. Può eseguire solo azioni consentite dal set di autorizzazioni parzialmente attendibile, se esistente, del dominio. Il codice Transparent non può eseguire le operazioni seguenti:

  • Eseguire un metodo Assert o un'elevazione dei privilegi.

  • Contenere codice di tipo unsafe o non verificabile.

  • Chiamare direttamente codice Critical.

  • Chiamare codice nativo o codice con l'attributo SuppressUnmanagedCodeSecurityAttribute.

  • Chiamare un membro protetto da LinkDemand.

  • Ereditare dai tipi Critical.

  Inoltre, i metodi Transparent non possono eseguire l'override di metodi virtuali Critical o implementare metodi di interfaccia Critical.

• Il codice SafeCritical è completamente attendibile ma può essere chiamato dal codice Transparent. Espone una superficie di attacco limitata di codice con attendibilità totale. Le verifiche della correttezza e della sicurezza vengono eseguite in codice SafeCritical.

• Il codice SecurityCritical può chiamare qualsiasi tipo di codice ed è completamente attendibile, ma non può essere chiamato da codice Transparent.

Di seguito sono elencate le diverse sezioni di questo argomento:

• Esempi di utilizzo e comportamenti

• Modelli di override

• Regole di ereditarietà

• Informazioni e regole aggiuntive

Esempi di utilizzo e comportamenti

Per specificare le regole di .NET Framework 4 (trasparenza di livello 2), utilizzare l'annotazione seguente per un assembly:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Per utilizzare le regole di .NET Framework 2.0 (trasparenza di livello 1), utilizzare l'annotazione seguente:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Se non si annota un assembly, per impostazione predefinita vengono utilizzate le regole di .NET Framework 4. La procedura consigliata prevede tuttavia l'utilizzo dell'attributo SecurityRulesAttribute anziché dell'impostazione predefinita.

Annotazione a livello di assembly

Le regole seguenti si applicano all'utilizzo degli attributi a livello di assembly.

• Nessun attributo: se non si specificano attributi, il runtime interpreta tutto il codice come SecurityCritical, tranne nei casi in cui tale caratteristica viola una regola di ereditarietà, ad esempio quando si esegue l'override o l'implementazione di un metodo virtuale Transparent o di interfaccia. In tali casi, i metodi sono SafeCritical. Se non si specificano attributi, Common Language Runtime determina automaticamente le regole di trasparenza.

• SecurityTransparent: tutto il codice è Transparent. L'intero assembly non eseguirà operazioni con privilegi o non sicure.

• SecurityCritical: tutto il codice introdotto dai tipi di questo assembly è Critical, mentre tutto l'altro codice è Transparent. Questo scenario è simile al caso in cui non vengono specificati attributi. Tuttavia Common Language Runtime non determina automaticamente le regole di trasparenza. Se si esegue ad esempio l'override di un metodo virtuale o astratto oppure si implementa un metodo di interfaccia, per impostazione predefinita tale metodo è Transparent. È necessario annotare in modo esplicito il metodo come SecurityCritical o SecuritySafeCritical; in caso contrario, verrà generata un'eccezione TypeLoadException durante il caricamento. Questa regola si applica anche quando la classe di base e la classe derivata si trovano nello stesso assembly.

• AllowPartiallyTrustedCallers (solo livello 2): tutto il codice è Transparent per impostazione predefinita. I singoli tipi e membri possono tuttavia avere altri attributi.

Nella tabella seguente viene confrontato il comportamento a livello di assembly per il livello 2 con quello per il livello 1.

Annotazione dei tipi e dei membri

Gli attributi di sicurezza applicati a un tipo si applicano anche ai membri introdotti dal tipo. Non si applicano tuttavia a override virtuali o astratti della classe di base o delle implementazioni dell'interfaccia. Le regole seguenti si applicano all'utilizzo degli attributi a livello di tipo e membro:

• SecurityCritical: il tipo o il membro è Critical e può essere chiamato solo da codice con attendibilità totale. I metodi introdotti in un tipo SecurityCritical sono Critical.

  Importante
  I metodi virtuali e astratti introdotti in classi di base o interfacce e sottoposti a override o implementati in una classe SecurityCritical sono Transparent per impostazione predefinita.Devono essere identificati come SecuritySafeCritical o come SecurityCritical.

• SecuritySafeCritical: il tipo o il membro è SafeCritical Il tipo o il membro può tuttavia essere chiamato da codice Transparent (parzialmente attendibile) e funziona come qualsiasi altro codice Critical. Il codice deve essere controllato per garantirne la sicurezza.

Torna all'inizio

Modelli di override

Nella tabella seguente vengono elencati gli override dei metodi consentiti per la trasparenza di livello 2.

Torna all'inizio

Regole di ereditarietà

In questa sezione, l'ordine seguente è assegnato al codice Transparent, Critical e SafeCritical in base all'accesso e alle funzionalità:

Transparent < SafeCritical < Critical

• Regole per i tipi: da sinistra verso destra l'accesso diventa più restrittivo. I tipi derivati devono essere restrittivi almeno quanto il tipo di base.

• Regole per i metodi: i metodi derivati non possono modificare l'accessibilità dal metodo di base. Per il comportamento predefinito, tutti i metodi derivati non annotati sono Transparent. I derivati di tipi Critical provocano un'eccezione se il metodo sottoposto a override non è annotato in modo esplicito come SecurityCritical.

Nella tabella seguente vengono elencati i modelli dell'ereditarietà dei tipi consentiti.

Nella tabella seguente vengono elencati i modelli di ereditarietà dei tipi non consentiti.

Nella tabella seguente vengono elencati i modelli di ereditarietà dei metodi consentiti.

Nella tabella seguente vengono elencati i modelli di ereditarietà dei metodi non consentiti.

Nota
Queste regole di ereditarietà si applicano a tipi e membri di livello 2.I tipi di assembly di livello 1 possono ereditare dai membri e dai tipi SecurityCritical di livello 2.Pertanto, i tipi e i membri di livello 2 devono disporre di richieste di ereditarietà separate per gli eredi di livello 1.

Torna all'inizio

Informazioni e regole aggiuntive

Supporto LinkDemand

Nel modello di trasparenza di livello 2, LinkDemand è stato sostituito dall'attributo SecurityCriticalAttribute. Nel codice legacy (livello 1), LinkDemand viene trattato automaticamente come Demand.

Reflection

Se si richiama un metodo Critical o si legge un campo Critical, viene generata una richiesta di attendibilità totale, come se si stesse richiamando un metodo o un campo Private. Il codice con attendibilità totale può pertanto richiamare un metodo Critical, a differenza del codice parzialmente attendibile.

Le proprietà seguenti sono state aggiunte allo spazio dei nomi System.Reflection per determinare se il tipo, il metodo o il campo è SecurityCritical, SecuritySafeCriticalo SecurityTransparent: IsSecurityCritical, IsSecuritySafeCriticale IsSecurityTransparent. Utilizzare queste proprietà per determinare la trasparenza tramite reflection anziché verificare la presenza dell'attributo. Le regole di trasparenza sono complesse ed è possibile che la verifica dell'attributo non sia sufficiente.

Nota
Un metodo SafeCritical restituisce true sia per IsSecurityCriticalche per IsSecuritySafeCritical, in quanto SafeCritical è Critical, ovvero ha le stesse funzionalità del codice Critical, ma può essere chiamato dal codice Transparent.

I metodi dinamici ereditano la trasparenza dei moduli a cui sono allegati, mentre non ereditano la trasparenza del tipo, nel caso in cui siano allegati a un tipo.

Ignorare la verifica in attendibilità totale

È possibile ignorare la verifica degli assembly Transparent completamente attendibili impostando la proprietà SkipVerificationInFullTrust su true nell'attributo SecurityRulesAttribute:

[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]

La proprietà SkipVerificationInFullTrust è false per impostazione predefinita, pertanto deve essere impostata su true per ignorare la verifica. Questa operazione deve essere eseguita solo per ottimizzare le prestazioni. È necessario assicurarsi che il codice Transparent dell'assembly sia verificabile tramite l'opzione transparent nello strumento PEVerify.

Torna all'inizio

Vedere anche

Concetti

Codice SecurityTransparent, livello 1

Modifiche della sicurezza in .NET Framework 4