Pagina 1 di 3 1 2 3 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 26
  1. #1
    Utente di HTML.it
    Registrato dal
    Apr 2006
    Messaggi
    87

    Problemi protezione

    Salve a tutti, vi espongo subito il mio problema (faccio notare che sono agli inizi con .net):
    -ho scritto un programma di prova (che semplicemente manda un messaggio con una msgbox) e ho provato a lanciarlo in locale su ogni pc della rete e funziona correttamete; i problemi nascono quando copio il programma sulla cartella condivisa del server (a cui accedono gli utenti) e quando provo a lanciarlo dal pc dell' utente, in quanto mi salta fuori un messaggio di security.exception.
    Come posso fare per sistemare la cosa? Forse devo impostare qualcosa nel pannello di configurazione .net oppure metterlo come assembly attendibile??
    GRAZIE MILLE ciao

  2. #2
    Si tratta di uno degli ottimi meccanismi di protezione di .NET Framework; tuttavia non si dovrebbe verificare una SecurityException in un assembly Partially Trusted (come quelli eseguiti da un drive di rete) a meno che esso non si colleghi ad assembly senza strong name o con strong name ma senza l'attributo "AllowPartiallyTrustedCallers". Questa eccezione può anche verificarsi con un assembly Partially Trusted che direttamente o indirettamente effettua chiamate a codice unmanaged. Verifica tra gli assembly a cui fai riferimento se ne compare uno o più che non rispetta questi requisiti.
    In ogni caso ecco un consiglio per risolvere radicalmente il tuo problema senza compromettere la sicurezza CAS:
    Primo passo: dare uno strong name ai tuoi assembly:
    • con l'utility sn (inclusa nel .NET Framework SDK) crea una nuova coppia di chiavi per firmare i tuoi assembly; nello specifico apri il prompt dei comandi nella directory in cui è contenuto sn.exe e digita sn -k nomefile.snk, dove nomefile è il nome del file che conterrà la tua nuova coppia di chiavi strong name;
    • copia il tuo file snk nella tua directory di sviluppo (di solito è qualcosa come Documenti\Visual Studio Projects) e non darlo in giro;
    • aggiungi al file assemblyinfo.vb di ogni tuo progetto di cui devi esegure il deploy su tutta la rete l'attributo <Assembly: AssemblyKeyFile("percorsocompleto\nomefile.snk")> (dove ovviamente percorsocompleto è il percorso completo della cartella in cui è contenuto il tuo file snk e nomefile.snk è il suo nome);
    • ricompila i vari progetti.

    A questo punto tutti i tuoi assembly saranno dotati di uno strong name e relativa chiave pubblica.
    Secondo passo: dire a .NET Framework di fidarsi del tuo Strong Name
    • Metti in rete o su un dischetto un tuo assembly con strong name;
    • su una delle tue macchine apri il tool .NET Configuration (è in Strumenti di Amministrazione);
    • nell'albero di cartelle posto nella parte sinistra della finestra spostati in Risorse del Computer\Criteri di protezione\Enterprise\Gruppi di Codice\All_code;
    • fai click di destro su All_code e seleziona "Nuovo...";
    • come nome inserisci qualcosa tipo "Assembly interni con strong name" o quello che vuoi; come descrizione metti "Dà agli assembly creati con lo strong name dell'amministratore tutti i privilegi";
    • come condizione metti "Nome sicuro", e sotto fai click su "Importa..."; con la finestra "Importa nome sicuro dall'assembly" apri l'eseguibile di un tuo progetto con strong name che avevi messo su un dischetto o in rete;
    • assicurati che nel campo "Chiave pubblica" ci siano una serie di cifre, e che le caselle Nome e Versione NON abbiano la spunta;
    • fai click su "Avanti";
    • assicurati che sia selezionato "Utilizza set di autorizzazioni esistente" e che nell'elenco a discesa sia selezionato "FullTrust";
    • fai click su "Avanti" e quindi su "Fine".

    Passo tre: distribuire i nuovi settaggi su tutta la rete
    • Una volta creato il criterio di cui al passo precedente, nel .NET Configuration fai click di destro su "Criteri di protezione runtime" e seleziona "Crea package di distribuzione...";
    • assicurati che sia selezionata la casella "Enterprise" e facendo click sul pulsante "Sfoglia..." scegli il posto dove salvare il file msi che verrà creato;
    • fai click su "Avanti" e quindi su "Fine";
    • copia il file msi così creato su una cartella condivisa sul server;
    • loggato da amministratore lancia il pacchetto msi su tutti i PC su cui vorrai eseguire le tue applicazioni .NET.

    Fine! A questo punto tutti i PC su cui avrai eseguito il pacchetto MSI si fideranno ciecamente di tutti gli assembly .NET firmati con il tuo strong name.
    @mod: questa mi parrebbe una buona pillola...
    Amaro C++, il gusto pieno dell'undefined behavior.

  3. #3
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,301
    Originariamente inviato da MItaly
    @mod: questa mi parrebbe una buona pillola...
    E' ciò che pensavo mentre leggevo...
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  4. #4
    Utente di HTML.it
    Registrato dal
    Apr 2006
    Messaggi
    87
    Ti ringrazio per la tua esaustiva risposta, purtroppo però continua a non funzionare.
    Ho seguito passo passo tutto quello che mi hai scritto ma quando tento di lanciare il programma (situato sempre nella cartella condivisa del server a cui accedono gli utenti) mi dà errore di policyException.
    Ho quasi perso le speranze di far andare programmi .net sulla LAN, tornerò al vecchio VB6 , GRAZIE MILLE comunque ciao

  5. #5
    Originariamente inviato da pol86
    purtroppo però continua a non funzionare.
    Mi sento ferito nell'orgoglio. Dai un ceffone ai PC in questione da parte mia.
    Ho seguito passo passo tutto quello che mi hai scritto ma quando tento di lanciare il programma (situato sempre nella cartella condivisa del server a cui accedono gli utenti) mi dà errore di policyException.
    Sto lavorando per perfezionare il metodo sopra indicato; mi sono accorto anch'io che ha qualche pecca, e ora vedo di sistemarlo.
    Ho quasi perso le speranze di far andare programmi .net sulla LAN
    Be', al limite basta disattivare il CAS, ma non è proprio il CAS...o (vabbé, soprassediamo...).
    tornerò al vecchio VB6
    Non farmi questo: ci sono voluti sei anni perché Microsoft mandasse in pensione quel maledetto linguaggio, non riesumarlo...
    Amaro C++, il gusto pieno dell'undefined behavior.

  6. #6
    Utente di HTML.it
    Registrato dal
    Apr 2006
    Messaggi
    87
    Sono pienamente daccordo con te sul fatto che il .NET sia su un altro pianeta rispetto a VB6, ma purtroppo con sto errore di policyException ci ho già sbattuto la testa troppe volte e non riesco a far andare nessun programma nelle aziende, dove naturamente gli eseguibili vengono utilizzati dagli utenti sulla cartella condivisa di windows server 2003 a cui accedono.
    Non capisco a questo punto la politica microsoft: hanno fatto un eccellente linguaggio (per non parlare di vs2005) ma tutti questi problemi di protezione (mi rirferisco anche ad asp .net dove sono stato notti senza dormire per farlo andare) mi stanno facendo crollare.
    Ripongo in te le mie ultime speranze CIAO

  7. #7
    Forse ci siamo: prova ad andare nelle proprietà della policy creata al passo due e nella scheda "generale" seleziona la casella "I livelli di criteri al di sotto di questo livello non verranno valutati". In questa maniera sul mio PC riesco ad eseguire assembly che invocano codice unmanaged firmati con il mio strong name anche da drive di rete. Ovviamente dovrai rieseguire in toto il terzo passaggio, il deployment del criterio su tutte le macchine.
    Non condivido invece la tua affermazione sui "problemi di protezione": Microsoft ha realizzato un eccellente linguaggio e l'ha corredato di eccellenti sistemi di protezione; i gruppi di codice sono una gran furbata, che ti permettono di limitare l'accesso alle risorse agli assembly di dubbia provenienza (come quelli situati sulla LAN o peggio su Internet), e se li si sa usare possono essere veramente molto utili.
    Amaro C++, il gusto pieno dell'undefined behavior.

  8. #8
    Utente di HTML.it
    Registrato dal
    Apr 2006
    Messaggi
    87
    Quando parlo di problemi di protezione mi riferisco al fatto che sono io ad avere problemi nella loro configurazione e penso che anche tu sia daccordo sul fatto che richiedono delle competenze che per esempio in vb6 non era necessario avere.

  9. #9
    Utente di HTML.it
    Registrato dal
    Apr 2006
    Messaggi
    87
    Ho provato e riprovato seguendo tutto quello che mi hai detto, ma NON FUNZIONA
    Sono preda dello sconforto ora mai, e sono sempre più dell' idea che se non accade un miracolo non riuscirò mai ad utilzzare .net.
    Mi sembra incredibile che sia cosi difficile configurare i settaggi di protezione, addirittura cercando su internet ho trovato delle procedura ancora più complesse, senza uno standard da seguire o quanto meno dei passaggi comuni.
    Sono costretto ad arrendermi perchè non ho la benchè minima idea di come risolvere il problema, ti ringrazio della tua disponibilità e se ti viene in mente qualche atro accorgimento fammi sapere GRAZIE.

  10. #10
    Utente di HTML.it
    Registrato dal
    Apr 2006
    Messaggi
    87
    F U N Z I O N A !!!
    Ho impostato su modifica protezione->Esegui modifiche solo per l'utente corrente->Intranet locale Attendibilità totale e il programma funziona perfettamente.
    CIAO e grazie per la tua collaborazione

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.