2013-07-12 11 views
12

Qualcuno ha esperienza con il codice F # in scenari di fiducia parziale? Come in, creazione di assiemi con [<AllowPartiallyTrustedCallers>]?Come utilizzare efficacemente gli assembly F # per il trust parziale?

Sto lavorando a un paio di progetti che dobbiamo essere in grado di eseguire in parziale attendibilità e abbiamo cercato di utilizzare le regole di sicurezza di Livello 2 (http://msdn.microsoft.com/en-us/library/dd233102.aspx). In pratica per i nostri assemblaggi autosufficienti è facile: basta mettere un attributo; ma a volte i nostri assembly fanno riferimento a DLL di terze parti che non sono annotate e presuppongono "SecurityCritical". Questo è dove diventa "interessante".

Avendo lavorato con esso per un paio di giorni sembra esserci un problema serio con F #. La politica di sicurezza di .NET prevede di annotare tipi/metodi con [<SecuritySafeCritical>] se fanno riferimento o chiamano il codice "SecurityCritical", il che sembra essere la maggior parte del codice disponibile in NuGet perché questo è il valore predefinito. Ora, in F # funziona bene fino a quando non inizi a utilizzare chiusure. Non si può fare:

namespace Foo 

open System.Security 

[<assembly: AllowPartiallyTrustedCallers>] 
[<assembly: SecurityRules(SecurityRuleSet.Level2)>] 
do() 

[<SecurityCritical>] 
module C = 
    let get() = [ 1 .. 10 ] 

[<SecuritySafeCritical>] 
module M = 

    let foo() = 
     seq { 
      for i in 1 .. 10 do 
       yield! 
        C.get() 
        |> Seq.filter (fun x -> x % 2 = 0) 
     } 

Questo gruppo non riesce a passare SecAnnotate.exe controlli perché compilatore F # alza la chiusura a un tipo separato, che ora non è annotato con [<SecuritySafeCritical>], il default è trasparente, ma i riferimenti po 'di codice critica, che è un errore.

Sembra una limitazione minore, ma mi è costato molte ore modificare il codice per evitare chiusure e soddisfare i vincoli SecAnnotate. Forse F # potrebbe propagare gli attributi di sicurezza ai tipi di chiusura che crea? C'è un altro modo semplice intorno a questo che mi manca?

risposta

6

È possibile applicare SecurityCritical come un attributo al livello di assembly:

[<assembly: SecurityCritical>] 

Un approccio migliore, però, supponendo che si sta solo scrivendo un assembly # "plain" F - vale a dire, uno che non sta facendo nulla che richiede speciali di sicurezza (ad esempio, P/Invoke) - potrebbe essere quella di sostituire:

[<assembly: AllowPartiallyTrustedCallers>] 

con

[<assembly: SecurityTransparent>] 

La pagina di MSDN per SecurityTransparentAttribute dice:

Specifica che un assembly non può causare un'elevazione di privilegi.

Gli assembly trasparenti sono accessibili da codice parzialmente attendibile e non possono esporre l'accesso a risorse o funzionalità protette. Il codice nell'assembly non è autorizzato a sopprimere i controlli di sicurezza per l'accesso al codice e non può causare un'elevazione dei privilegi.

Anche la versione F # 3.0 di FSharp.Core utilizza questo attributo per lo stesso motivo.

Collegamenti a ulteriori informazioni:

+0

Grazie per i link!Sfortunatamente nel mio scenario sto cercando di abilitare il codice parzialmente attendibile per chiamare 'SecurityCriticalCode' di terze parti (codice non annotato), quindi sembra che io * abbia * bisogno di APTCA +' [] ', almeno da qualche parte .. – t0yv0

+0

Potrebbe essere possibile usare '[]' quindi selezionare qualsiasi metodo/funzione che chiama nell'assembly di terze parti con '[]'. Penso che funzionerà nella maggior parte delle situazioni di fiducia parziale, ad eccezione di Silverlight. –

+0

Dopo aver contrassegnato un assembly come SecurityTransparent, non è più possibile utilizzare SecuritySafeCritical - provare con SecAnnotate.exe, si lamenta. Pertanto, l'assemblaggio deve essere APTCA. Ma grazie comunque, credo di essere sulla strada giusta, dovrò solo vivere con le inutili complicazioni che F # fa per farlo. – t0yv0

Problemi correlati