Sicurezza dell'accesso al codice .NET: utile o semplicemente complicata?

Question

  

vedi anche & # 8220; Accesso al codice Sicurezza # 8221 &; di   qualche uso nel mondo reale?

Voglio avere altre opinioni su questo ...

Mi piace l'idea di Code Access Security per le applicazioni desktop. Ma nel corso della vita di .NET devo ammettere che non ho mai avuto una situazione in cui CAS ha effettivamente bloccato qualcosa a mio vantaggio.

Tuttavia, ho avuto molte volte in cui qualcosa di semplice come la condivisione di un'applicazione .NET rapida su un'unità mappata diventa un incubo di accesso al codice aziendale. Dovendo rompere caspol.exe per creare regole di percorso attendibili e non avere un modo chiaro di sapere perché qualcosa non funziona fa sembrare che CAS aggiunge molta più frustrazione al processo di sviluppo e distribuzione di quanto offra in sicurezza.

Mi piacerebbe sentire alcune situazioni in cui CAS ha effettivamente aiutato più che male, o se ci sono altre persone là fuori frustrate dalla sua attuale implementazione e dai valori predefiniti.

Answer 1

Il team .NET stesso è giunto alla stessa conclusione che la sicurezza dell'accesso all'assembly è stata rielaborata per .NET # 4. Dai un'occhiata a questo blog per maggiori informazioni: Blog sulla sicurezza in .NET

Answer 2

Qui, qui! Ho condiviso molte delle stesse frustrazioni. E, naturalmente, l'eccessiva complicazione e l'orrenda documentazione in sostanza incoraggiano gli sviluppatori a bypassarla o ad usare regole troppo ampie. La sicurezza sarà sempre un dado duro per chiunque, ma CAS è davvero difficile da fare nel modo giusto.

Answer 3

Ho avuto a che fare con CAS, ma non è stato troppo difficile poiché ho dovuto distribuirlo solo su una dozzina di stazioni di lavoro o giù di lì. Puoi anche inviare le impostazioni richieste tramite Criteri di gruppo.

Ma per rispondere alla tua domanda, no, non credo che abbia mai aiutato.

Guarda il lato positivo però, a partire da .NET 3.5 puoi eseguire app attraverso una condivisione di rete senza CAS.

Answer 4

Dopo molte ricerche mi sono imbattuto in questo post di blog del team CLR che non solo conferma che CAS sta andando via in .NET 4, ma offre anche un'ottima guida su cosa si romperà e su come migrare verso il nuovo modello sandbox: Nuovo modello di sicurezza: passare a una sandbox migliore . Dall'articolo:

  

Nelle versioni di .Net Framework precedenti   v4, avevamo molti modi per limitare il   permessi di un assembly o anche   certo percorso del codice all'interno dell'assembly:

     

  

1. Modificatori Stack-walk: Nega, PermitOnly

  

2. Richieste a livello di assembly: RequestOptional, RequestRefuse,   RequestMinimum

  

3. Modifiche ai criteri: caspol e AppDomain.SetPolicyLevel

  

4. Caricamento di un assieme con una zona diversa da MyComputer

  

     

In passato, queste API sono state a   fonte di confusione per host e   scrittori di applicazioni. In .Net Framework   4, questi metodi di limitazione   le autorizzazioni sono contrassegnate come obsolete e noi   spero di rimuoverli in un punto nel   futuro.

La cosa più angosciante è il fatto che tutti questi metodi deprecati per creare una sandbox inizieranno a lanciare un NotSupportedException. Ciò è eccezionalmente precario per le anime povere (come me) che per qualsiasi motivo sono richieste per implementare CAS nella loro organizzazione in questo momento. Sei stato avvisato.