Newsgroup: it.comp.sicurezza.varie
Titolo: TrueCrypt in rete locale

Un volume (file o partizione) TrueCrypt che risiede su un fileserver 
permette l'accesso simultaneo in lettura/scrittura da più utenti per 
volta? Potete segnalarmi dei link per favore? Grazie.

Potete segnalarmi dei link per favore?
file://<letteradelvolume>|/
Leonardo
-- 
Geordie - he's a man, there's little doot about't,
He's done all he can, wha' can do withoot't?
Doon there cam a blade, linkin' like me lordie,
He wad drive a trade, a' the loom of Geordie.

 file://<letteradelvolume>|/
Intendevo un link a una pagina dove si danno maggiori informazioni, grazie.

 Leonardo
Sì, se intendi che il server monta il file TC come un volume che poi
condivide; no (almeno per quanto ne so), se intendi che diversi client
montano un file TC che si trova su un server.
Questo perché Windows come server non gestisce un meccanismo di
concorrenza nelle singole parti di un file.
Ciao.

Intendevo un link a una pagina dove si danno maggiori informazioni, grazie.
Voleva essere una battuta: non c'e' motivo per cui non si possa fare, e'
il comportamento normale del sistema.
Sarebbe anzi difficile IMPEDIRLO.
Poi, basta che tu faccia una prova.


montano un file TC che si trova su un server.
Ahhh no, a quello non ci avevo neppure pensato. Io intendevo: TrueCrypt
installato sul server, che esporta le share in chiaro. Per quello stavo
dicendo "e' un volume come un altro".


 Leonardo
Però questo sarebbe più interessante, perché anche il traffico sarebbe
costituito da dati cifrati.
Ciao.

 costituito da dati cifrati.
Sì, era proprio quello che pensavo. Grazie per avere interpretato 
correttamente la mia domanda un poco imprecisa.

costituito da dati cifrati.
Vero, ma come fare a coordinare le operazioni tra i vari client?
L'unico aggeggio che fa qualcosa di vagamente simile e' Zetera, che e'
un po' il Norton dei sistemi di storage :-)
A quel punto forse sarebbe meglio criptare il traffico di rete e amen.


 Vero, ma come fare a coordinare le operazioni tra i vari client?
TrueCrypt _se_non_sbaglio_ non implementa una soluzione di accesso
concorrente.
Mi viene in mente la soluzione adottata per sqlite (dove più client
aprono il file e lavorano in contemporanea), credo sarebbe interessante
implementarla per TrueCrypt.

aprono il file e lavorano in contemporanea)
Si', ma in questo caso l'accesso concorrente avviene da client su macchine
diverse; e il pager dovrebbe girare come processo distribuito. Credo.


 Leonardo
no.
testato e funzionante sqlite su file condivisi tramite NFS sapendo che
tutti i client hanno fcntl().
(con samba nn ci ho provato, ma leggendo sotto non mi fiderei).
il pager si occupa di usare i lock del filesystem.
Dalle FAQ di SQLITE:
SQLite uses reader/writer locks to control access to the database.
(Under Win95/98/ME which lacks support for reader/writer locks, a
probabilistic simulation is used instead.) But use caution: this locking
mechanism might not work correctly if the database file is kept on an
NFS filesystem. This is because fcntl() file locking is broken on many
NFS implementations. You should avoid putting SQLite database files on
NFS if multiple processes might try to access the file at the same time.
On Windows, Microsoft's documentation says that locking may not work
under FAT filesystems if you are not running the Share.exe daemon.
People who have a lot of experience with Windows tell me that file
locking of network files is very buggy and is not dependable. If what
they say is true, sharing an SQLite database between two or more Windows
machines might cause unexpected problems.
Ritornando a TrueCrypt ci si sbatte sullo stesso problema, riassumendo:
- Se TrueCrypt monta il volume e lo condivide -> NO PROBLEM
- Se Vari TrueCrypt montano il volume in concorrenza , date che il file
locking su rete in windows è fondamentalmente buggato (pare, qualcuno
confermi ?!?) non funziona...
Saluti

il pager si occupa di usare i lock del filesystem.
Capito. Per TrueCrypt pero' il problema e' piu' complesso, perche' per
vedere un "volume" bisogna che tu esporti un sacco di roba verso l'IFS
che fa caching (si puo' disattivare il write-behind, ma non il resto).
Per esempio, il driver TC sulla workstation A accede al volume chiuso,
sul server; acquisisce un lock in lettura per la zona della MFT, che a
questo punto viene decriptata sul client e resa disponibile all'IFS, e
di qui all'utente (e uno vede il volume V:).
Ora la workstation B accede allo stesso volume, acquisisce un lock, ma
apre anche un file. Viene modificato l'atime del file, che sta in MFT,
che va scritta -- e come si informa la workstation A?
Se la workstation A ha rilasciato il lock, puo' pero' darsi che grossi
pezzi della MFT del volume siano ancora in memoria; A non "vede" alcun
cambiamento sul volume.
Ci vorrebbe un meccanismo per trasmettere un segnale di "Rileggi tutto
il disco" fra i vari client TC.
Il fatto e' che non c'e' "un" volume letto dal server; il "volume" non
esiste sul server, dove c'e' solo un file; esistono vari "volumi" che,
idealmente, sono tutti uguali, su ciascun client. Le modifiche fatte a
livello dei files su quel volume non hanno effetto sui volumi virtuali
degli altri client.
So che ci sono sistemi per aggirare il problema perche' ho visto tower
SCSI collegati a quattro computer in parallelo, e so che si puo' farlo
via software perche' ZeteraService fa proprio questo. Non ho pero' una
idea chiara del come farlo; ho il dubbio che si dovrebbe riscrivere un
bel pezzo di TrueCrypt.


 che fa caching (si puo' disattivare il write-behind, ma non il resto).
<snippone>
Non credo che TC sia stato pensato per una cosa del genere; ed in ogni
caso, come già detto, sarebbe più semplice implementare la crittografia
a livello di trasporto (es. IPSec o simile) invece di utilizzare TC per una
cosa per la quale non è stato progettato e che in ogni caso sarà un grosso
collo di bottiglia; a questo punto tanto varrebbe fare tunnelling di NFS su
ssh oppure usando s/w tipo stunnel, zebedee o simili evitando così i vari
problemi e l'overhead causato dall'uso di un volume in rete
ciao