Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]
Il giorno 15 novembre 2010 20:13, Manlio Perillo ha scritto: > Se embeddi l'interprete, ti basta settare il flag Py_NoSiteFlag. > Ah, beh tanto meglio :) > Scusa, ma nel tuo caso chiami l'interprete dalla riga di comando, o è > incluso nella tua applicazione? > Nel progetto di cui alla discussione precedente includo l'interprete nel programma C, però visto che tale thread è stato cosi ricco di spunti ho pensato di provare a vedermi un po' il meccanismo di import di CPython. Peccato che questa funzione non sia personalizzabile. > > Io l'ho modificata per caricare, assieme a zipimport, anche il modulo signedimporter (quello tuo da paste, anche se incompleto mi serviva per test. Per maggiore sicurezza, però, anzichè usare il comportamento standard di python con zipimport,(ovvero, che se non riesce a caricare il modulo o ad ottenere un riferimento alla funzione/classe che gestisce l'import scrive sullo stderr solo in caso di PYTHONVERBOSE) ho preferito far stampare l'errore ed interrompere l'esecuzione dell'interprete (scelta non necessariamente definitiva). Ho notato comunque che zipimport viene registrato non in sys.meta_path ma in sys.path_hooks. Stando alla PEP302 mi pare di aver capito che la differenza è che sys.meta_path viene controllato *prima* della creazione di sys.path. E poi in meta_path si parla di importer mentre in path_hooks di oggetto callable. :S Per ora funziona tutto, cioè non ci sono errori a runtime anche se giustamente, il modulo signedimporter non fà nulla e poi dovrò aggiungere un controllo integrato per la validità dello stesso .py (magari poi lo rifarò in C se conviene). Unico problema trovato in fase di compilazione del sorgente è che il modulo hashlib crea un errore cercando di importare _md5, anche se, onestamente, non capisco perchè in fase di compilazione tenti di eseguire il modulo signedimporter (che importa hashlib). > Ti consiglio anche di chiedere sul newsgroup inglese. > > Uhm, gli darò un'occhiata. Sicuro che non mi mangiano se parlo di modificare la base di python? =E > Ciao Manlio > Ciao ciao! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [ANN] secimport
Ma bene :) Seguo con attenzione gli sviluppi, e mi permetto di usarlo per test, e usare i file aggiornati al posto del signedimporter di paste, per la modifica a CPython. Se faccio modifiche o scovo qualcosa (o se ho dubbi) ti avviso :) Buono sviluppo! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [ANN] secimport
On Mon, Nov 15, 2010 at 07:56:54PM +0100, Manlio Perillo wrote: [...] > secimport ? un import hook che permette di verificare ciascun modulo > importato usando una database di "firme" di ciascun modulo. > Una "firma" ? semplicemente un hash (personalizzabile, tramite il modulo > hashib.new) del file dove il modulo si trova. > [...] > > In fase di installazione verr? creato uno script > `build_signature_database.py`, che si occupa di creare il database (un > semplice dizionario) di *tutti* i moduli Python accessibili dalla > instanza dell'interprete utilizzata. > > Al momento lo script include anche alcuni moduli non importabili (non ? > un problema ma ? da sistemare). > > > IMPORTANTE: la sicurezza ? tutta da verificare! qualche pensiero sparso a proposito. prima di tutto il modulo stesso deve essere importato e prima di essere importato non c'? nessun controllo sul modulo stesso, ergo basta modificare il modulo `secimport`. quando fai il controllo del file `__init__.py` si deve controllare anche i relativi `.pyc` e `.pyo`, infatti basta modificare a piacere il file `__init__.py`, copiare il bytecode nella giusta posizione, il file `__init__.py` rimane quello originale ma viene modificato l'mtime. `secimport` controlla il file `__init__.py` ma l'importer python caricher? il bytecode modificato. di questo punto non sono sicuro, ma non vengono effettuati controlli sulle estenzioni C, l'unico controllo ? un `assert` che come ho detto nell'altro thread pu? essere semplicemente eliminato compilando il codice python con le relative ottimizzazioni. gli `assert` servono solo per debug ed errori di programmazione. il file con gli hash dei vari moduli ? facilmente modificabile rendendo vano tutto il lavoro fatto. inoltre non ? da scartare il fatto che per ogni piccola modifica bisogna ricalcolare il relativo hash, questo rende la distribuzione pi? tediosa. come è stato detto bisogna fare un ragionamento di costi/benefici e lo stesso farà chi cerca di modificare il tuo programma. se il programma non interessa a nessuno tutto questo lavoro è inutile, senza considerare che tutto questo ha un costo che non porta nessun beneficio all'utente finale (il programma non sarà più efficiente/economico/robusto/ecc.) m. -- Cosa volete? Questo diavolo d'uomo ha sempre le tasche ripiene di argomenti irresistibili. -- Pierre Augustin Caron de Beaumarchais ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 16/11/2010 10:52, lex mlist ha scritto: > [...] > Scusa, ma nel tuo caso chiami l'interprete dalla riga di comando, o è > incluso nella tua applicazione? > > Nel progetto di cui alla discussione precedente includo l'interprete nel > programma C, però visto che tale thread è stato cosi ricco di spunti Sicuramente, ed è per questo che ho dedicato un paio di ore a secimport. Il problema però è capire i casi di uso. In quale casi hai bisogno di verificare l'integrità di tutti i moduli Python utilizzati? L'unico caso di uso che mi viene in mente è quando l'interprete python viene eseguito con privilegi particolare (ad esempio root, oppure accesso a porte IP). > [...] > > Ho notato comunque che zipimport viene registrato non in sys.meta_path > ma in sys.path_hooks. > Stando alla PEP302 mi pare di aver capito che la differenza è che > sys.meta_path viene controllato *prima* della creazione di sys.path. > E poi in meta_path si parla di importer mentre in path_hooks di oggetto > callable. :S > Al momento non sono sicuro della differenza tra i due, dovrei leggere il codice. > [...] > Unico problema trovato in fase di compilazione del sorgente è che il > modulo hashlib crea un errore cercando di importare _md5, anche se, > onestamente, non capisco perchè in fase di compilazione tenti di > eseguire il modulo signedimporter (che importa hashlib). > Parli della compilazione di python? Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzien8ACgkQscQJ24LbaUQqSwCfTz60XdmJY+kYE2gQsqTuE5WJ 3pkAnjPu2a/FC1Krt6nvDwx0PqFfIflj =zAFL -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] [ANN] secimport
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 16/11/2010 11:13, Marco Giusti ha scritto:
> On Mon, Nov 15, 2010 at 07:56:54PM +0100, Manlio Perillo wrote:
> [...]
>> secimport ? un import hook che permette di verificare ciascun modulo
>> importato usando una database di "firme" di ciascun modulo.
>> Una "firma" ? semplicemente un hash (personalizzabile, tramite il modulo
>> hashib.new) del file dove il modulo si trova.
>
> [...]
>
> qualche pensiero sparso a proposito.
>
> prima di tutto il modulo stesso deve essere importato e prima di essere
> importato non c'? nessun controllo sul modulo stesso, ergo basta
> modificare il modulo `secimport`.
>
Infatti per maggiore sicurezza l'hook può essere implementato in C.
Si parlava infatti del caso in cui una applicazione vuole embedare
l'interprete Python.
> quando fai il controllo del file `__init__.py` si deve controllare anche
> i relativi `.pyc` e `.pyo`, infatti basta modificare a piacere il file
> `__init__.py`, copiare il bytecode nella giusta posizione, il file
> `__init__.py` rimane quello originale ma viene modificato l'mtime.
> `secimport` controlla il file `__init__.py` ma l'importer python
> caricher? il bytecode modificato.
>
Questo è un punto su cui non sono sicuro.
Innanzitutto, comunque, secimport *non* controlla __init__.py ma il
modulo __init__.
fp, pathname, descr = imp.find_module('__init__', [self.pathname])
> di questo punto non sono sicuro, ma non vengono effettuati controlli
> sulle estenzioni C, l'unico controllo ?
No, quelle non sono estensioni C; sono moduli *builtin*, linkati
**staticamente** nell'interprete cpython.
> [...]
> il file con gli hash dei vari moduli ? facilmente modificabile rendendo
> vano tutto il lavoro fatto.
>
Il database delle firme va conservato in un posto sicuro.
Ad esempio nel codice sorgente (in C) dell'applicazione che embedda
cpython ed utilizzando opportune tecniche di offuscamento.
In alternativa si può utilizzare un algoritmo a chiavi pubbliche, nel
qual caso si deve proteggere solo la chiave.
> inoltre non ? da scartare il fatto che per ogni piccola modifica bisogna
> ricalcolare il relativo hash, questo rende la distribuzione pi? tediosa.
>
Dipende dai modi d'uso di un progetto che vuole utilizzare secimport.
> come è stato detto bisogna fare un ragionamento di costi/benefici e lo
> stesso farà chi cerca di modificare il tuo programma.
Sicuramente.
> se il programma
> non interessa a nessuno tutto questo lavoro è inutile, senza considerare
> che tutto questo ha un costo che non porta nessun beneficio all'utente
> finale (il programma non sarà più efficiente/economico/robusto/ecc.)
>
Ciao Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzifNwACgkQscQJ24LbaUTMywCffi9xB46geXt6BdkB11yQW2Z1
nfEAoI47+nbSLHZI5DiLnecOTjY4jH4b
=7cgp
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] [ANN] secimport
On Tue, Nov 16, 2010 at 01:45:16PM +0100, Manlio Perillo wrote:
[...]
> > prima di tutto il modulo stesso deve essere importato e prima di essere
> > importato non c'? nessun controllo sul modulo stesso, ergo basta
> > modificare il modulo `secimport`.
>
> Infatti per maggiore sicurezza l'hook pu� essere implementato in C.
> Si parlava infatti del caso in cui una applicazione vuole embedare
> l'interprete Python.
avevo capito ma comunque il modulo � stato scritto in python, non in C.
> > quando fai il controllo del file `__init__.py` si deve controllare anche
> > i relativi `.pyc` e `.pyo`, infatti basta modificare a piacere il file
> > `__init__.py`, copiare il bytecode nella giusta posizione, il file
> > `__init__.py` rimane quello originale ma viene modificato l'mtime.
> > `secimport` controlla il file `__init__.py` ma l'importer python
> > caricher? il bytecode modificato.
>
> Questo � un punto su cui non sono sicuro.
> Innanzitutto, comunque, secimport *non* controlla __init__.py ma il
> modulo __init__.
> fp, pathname, descr = imp.find_module('__init__', [self.pathname])
linea 78 in load_module, viene verificato il checksum del file
`__init__.py`.
> > di questo punto non sono sicuro, ma non vengono effettuati controlli
> > sulle estenzioni C, l'unico controllo ?
>
> No, quelle non sono estensioni C; sono moduli *builtin*, linkati
> **staticamente** nell'interprete cpython.
cancello dagli atti questa affermazione, non conosco bene `imp` ed
alcune mie assunzioni erano sbagliate.
ciao
m.
--
La calunnia � un venticello
Un'auretta assai gentile
Che insensibile, sottile,
Leggermente, dolcemente,
Incomincia a susurrar.
-- Basilio, Il barbiere di Siviglia
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] [ANN] secimport
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 16/11/2010 14:41, Marco Giusti ha scritto:
> On Tue, Nov 16, 2010 at 01:45:16PM +0100, Manlio Perillo wrote:
> [...]
>>> prima di tutto il modulo stesso deve essere importato e prima di essere
>>> importato non c'? nessun controllo sul modulo stesso, ergo basta
>>> modificare il modulo `secimport`.
>>
>> Infatti per maggiore sicurezza l'hook pu� essere implementato in C.
>> Si parlava infatti del caso in cui una applicazione vuole embedare
>> l'interprete Python.
>
> avevo capito ma comunque il modulo � stato scritto in python, non in C.
>
Da valutare comunque se si può fare qualcosa anche con il modulo scritto
in Python.
>>> quando fai il controllo del file `__init__.py` si deve controllare anche
>>> i relativi `.pyc` e `.pyo`, infatti basta modificare a piacere il file
>>> `__init__.py`, copiare il bytecode nella giusta posizione, il file
>>> `__init__.py` rimane quello originale ma viene modificato l'mtime.
>>> `secimport` controlla il file `__init__.py` ma l'importer python
>>> caricher? il bytecode modificato.
>>
>> Questo � un punto su cui non sono sicuro.
>> Innanzitutto, comunque, secimport *non* controlla __init__.py ma il
>> modulo __init__.
>> fp, pathname, descr = imp.find_module('__init__', [self.pathname])
>
> linea 78 in load_module, viene verificato il checksum del file
> `__init__.py`.
>
Hai ragione.
Mi sono letto l'implementazione di find_module e load_module, e:
* find_module cerca *prima* se esiste il corrispondente source module
* load_module -> load_source_module controlla se esiste il modulo
precompilato
Invece io stavo incorrettamente assumendo che find_module mi restituisse
direttamente il tipo di modulo corretto.
Quindi si, il codice va corretto; grazie.
> [...]
Ciao Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzimf4ACgkQscQJ24LbaUTzdQCfXWeLjWe6e+tqn9Lah09+dazn
RbwAn0JFaTcR3iVqZuNyNaQiWxdn+RN/
=Ul/9
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Nov 13, 2010, at 12:23 PM, lex mlist wrote: > Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente > decompilabile, hai quindi una qualche alternativa? > oppure un programma python è destinato a rimanere open source!? Open source vuole dire una cosa ben precisa. -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/16 Enrico Franchi : > > On Nov 13, 2010, at 12:23 PM, lex mlist wrote: Scusate, partito per errore. Avevo gia' risposto. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] SignedImporter [was: Criptazione dei file sorgenti per evitare la manomissione]
Il giorno 16 novembre 2010 13:35, Manlio Perillo ha scritto: > Il problema però è capire i casi di uso. > In quale casi hai bisogno di verificare l'integrità di tutti i moduli > Python utilizzati? > L'unico caso di uso che mi viene in mente è quando l'interprete python > viene eseguito con privilegi particolare (ad esempio root, oppure > accesso a porte IP). > Penso che sia necessario, oltre ai casi da te citati, nel caso in cui ad esempio Python venga utilizzato come scripting di un altro motore (poniamo l'esempio di un motore grafico, o di una applicazione tanto complessa da rendere necessaria tale scelta). In quel caso, qualora si possa voler preferire un linguaggio già pronto (anzichè fare un nuovo interprete che magari supporti i file binari per proteggere anche la logica), si rende necessario il poter operare in tutta tranquillità in una sandbox, e quindi controllare che non vi siano manomissioni a uno qualunque dei moduli utilizzati (altrimenti si comprometterebbe la stabilità e il flusso di lavoro del programma). Per fare un esempio mi vengono in mente solo applicativi di una certa stazza, che probabilmente, visto il loro valore, non si appoggerebbero mai ad una soluzione che ne esponga la logica. Boh, adesso non saprei precisamente il perchè di una scelta, magari come dici tu è solo perchè da root potrebbe compromettere l'intero sistema, ma se è un software destinato ad uso professionale penso che anche se non venga eseguito da root dovrebbe garantire sempre la corretta esecuzione, pensa se un utente modifica i file python, magari per sbaglio, e poi lavora sul software (poniamo che sia di disegno tecnico), clicca su 'Salva' e si rende conto che il menù File non funziona perchè la relativa funzione python è stata compromessa (e non è rara la scelta di un linguaggio di scripting per gestire l'interfaccia grafica, anzi). Invece controllando, all'avvio, eventualmente segnala che il programma necessita di essere reinstallato e boh. Se ho sbagliato qualcosa, correggetemi pure. Probabilmente ci sono altre motivazioni più valide, ma che non mi vengono in mente. > > Al momento non sono sicuro della differenza tra i due, dovrei leggere il > codice. > Io prevedo di farlo stasera, se ho un po' di tranquillità, nel caso scopro la differenza la posto qui subito. > > [...] > > Unico problema trovato in fase di compilazione del sorgente è che il > > modulo hashlib crea un errore cercando di importare _md5, anche se, > > onestamente, non capisco perchè in fase di compilazione tenti di > > eseguire il modulo signedimporter (che importa hashlib). > > > > Parli della compilazione di python? > Si, dopo aver modificato la '_PyImportHooks_Init' e compilando ottengo quell'errore. Se uso la stessa gestione che usano per zipimport ovvero, in caso di errore passaci sù, funziona giustamente. Però poi anche a runtime ad ogni avvio quella sarebbe la gestione dell'errore. Probabilmente avviene perchè hashlib non ha ancora accesso a tutte le sue dipendenze (magari devono essere compilate). Per provare ho lasciato passare l'errore, la soluzione definitiva sarebbe o fare il modulo in C (come lo è zipimport) o magari trovare un modo per aggirare il problema di hashlib. > > Ciao Manlio > Ciao e buona serata. PS. a questo punto, se dovesse rendersi necessario il fare troppe modifiche all'interprete per via di vari problemi nei moduli, si potrebbe pensare ad includere un nuovo file .c all'interprete e rendere il controllo parte integrante dell'interprete stesso, ovviamente se dovesse essere necessario farlo su *tutti* i moduli, permettendo però, di inserire in qualche modo il dizionario con le chiavi. Però mi suona di cosa che necessita la modifica dell'inizializzazione di CPython, perchè dovrebbe poter accedere ad un dato runtime (il dizionario), prima dell'inizializzazione e quindi dell'esecuzione effettiva del programma: forse la soluzione non è fattibile. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
