[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VFS, Smail, etc..



>From the keyboard of Therapy?:

> pfu wieder eine stressige woche .. man hat soviel vor und soviele probleme
> - wieso nicht fragn ob sie schon jemand geloest hat ;)
> 
> also mal das erste:
> 
> ich wuerd gern ein cryptographic network-based FS schreiben und hab mir
> das VFS von linux schon etwas naeher angeschaut - check auch habwegs
> alles, aber falls nicht wuerd ich gern wen fragen koennen ;)
> das ganze tcfs, smb, cifs, nfs, afs ist entweder dreck insecure oder
> kommerz :(.

Ah, das Projekt geistert auch schon länger in meinem Kopf herum. Ich
bilde mir sogar ein, nach dem letzten Treffen versprochen zu haben,
meine Ideen zusammenzuschreiben. Werd' ich noch ausführlich machen.

Prinzipell läufts auf folgendes hinaus: 

Anforderungen:

1) Resistent gegen HW-Ausfälle

2) Resistent gegen Unbefugte

3) Gute Performance beim Lesen von Files

4) Brauchbare Performance beim Schreiben von Files "am Stück"

Nicht-Anforderungen:

5) Absolute Konsistenz

6) Brauchbare Performance beim Random-Access- oder Append-Writes
 
Ideen für Implementierung:

Anforderungen 1) und 3) lassen sich wohl nur durch Replikation
erreichen. Die Replikation stelle ich mir so vor, daß es einen Pool von 
Disks auf verschiedenen Rechnern gibt, die gemeinsam ein Filesystem
bilden. Jedes File existiert mindestens auf 2 Disks (wenn möglich auf
zwei verschiedenen Rechnern). Wenn ein File geöffnet wird, wird es (wenn
nicht schon dort) auf eine lokale Platte kopiert.

Anforderung 2) macht Kryptographie notwendig. Die Frage ist, wo man
diese ansetzen soll. Man kann die Daten entweder nur während der
übertragung verschlüsseln, oder auch verschlüsselt auf der Platte
ablegen und bei jedem Lesen/Schreiben ent/verschlüsseln. Letzteres
hätte den Vorteil, daß Unbefugte auch mit der Platte bzw. den Backups
nichts anfangen können, aber den Nachteil relativ hoher CPU-Last.
Meine Idee wäre, prinzipiell Dateien verschlüsselt zu speichern, aber
durch Caching dort wo die Hardware sicherer ist als die Daten
geheim sind :-) die Performance zu verbessern. Files, die prinzipiell
world-readable sind, braucht man natürlich nicht zu verschlüsseln.

Anforderung 4) sollte (unter Verzicht auf 5) und 6)) dadurch erreicht
werden können, daß Änderungen an Files erst beim close auf andere
Rechner übertragen werden. 

Als Speicher- und Übertragungsformat hätte ich mir das PGP-Format
vorgestellt, weil das schon in der Praxis erprobt ist.

Irgendwann wird jede Platte voll, darum sollte ein Rechner bei erreichen
einer gewissen High-Water-Mark versuchen, alte Files wieder loszuwerden.
Wenn mindestens zwei andere Rechner dieses File haben, kann er es
einfach löschen. Wenn nicht, muß er jemanden finden, der es übernimmt. 

Offene Fragen: 

Wie bildet man das auf das Unix uid/gid-System ab? Von uid/gid auf PGP
ist es einfach: Jeder User und jede Group hat ein Key-Paar
(Nebenproblem: Wie entferne ich jemanden aus einer Gruppe? Er könnte
den Secret Key irgendwo abgespeichert haben). Umgekehrt muß das
irgendwie on-the-fly geschehen, oder es muß eine zentrale Tabelle geben.
Wenn in Linux die uid 32 bit hätte, wie in HP-UX könnte man einfach die
PGP Key-ID nehmen.

Leseberechtigung für mehrere Personen oder Gruppen ist in PGP leicht zu
verwirklichen. Das könnte in ACLs abgebildet werden (hat jemand den
relevanten POSIX-Standard? HP-UX ist in der Beziehung leider nicht
POSIX-konform).

Wie bilde ich Schreibberechtigung auf PGP ab? 

Was passiert, wenn ein File auf zwei Rechnern gleichzeitig geändert
wird? Letzter gewinnt? File wird gespalten? Merge der Änderungen?

> 2) weiss jemand unter welcher gid/uid der smail daemon normalerweise
> laeuft ?

Nein, smail habe ich nie verwendet.

> 3) kennt sich jemand mim ethernet & ip & tcp protocol naeher aus ?

Kommt drauf an, wie nahe. Ich weiß ungefähr wie's ausschaut, und habe
wohl auch einige Pakete in ihre Bits zerfieselt, aber wenn man das nicht
täglich macht, vergißt man die die Details immer wieder (zumindest
geht's mir so, manche Leute merken sich solche Sachen ewig).

> der typ der den bochs (80386 code emulator) geschrieben hat, hat naemlich
> noch keine emulation einer netzwerk karte. und das ist auch nicht so
> leicht - denn er kann dem bochs nicht einfach XS zu den I/O ports der
> netzwerk karte geben (vorallem wenns kein suid prog is) - sondern muss
> wahrscheinlich die ethernet packete analysiern bis er die tcp daten raus
> filtern kann ... ziemlich kompliziert..

Dann kannst Du aber nur TCP und UDP verwenden. Für ICMP (z.B. ping)
brauchst Du schon Raw-IP-Access, und dafür mußt Du root sein. Ich würde
vorschlagen, daß die Netzwerkkarten-Emulation die Ethernet-Pakete
einfach an ein suid-Programm weitergibt (vielleicht über Shared Memory,
das du irgendwo zwischen 0xA0000 und 0xFFFFF mappst, dann schaut's
sogar aus wie eine ISA-Karte) und das schreibt dann die Pakete raus,
bzw, liest sie. Das könnte dann auch entsprechende Checks (richtige
MAC/IP-Adressen, etc) machen.

>  ich hoffe ich hab zeit das reply zu lesen ;)))

Das hoffe ich auch - wenn ich schon einmal so einen Anfall von Logorrhoe
habe.

	hp



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010