Wirklich oje, ….. - Kasperskys Unix-Virenscanner ermöglicht …
Geschrieben von: admin in Allgemeinvirenscanner > Das hieße aber Du mußt eines der folgenden Dinge machen:
> >
> > > a) für jeden Nutzer einen Thread offen haben während Du die Platte
> > > durchsuchst
> > Ich benoetige pro Eigentuemer einen Prozess. Dies erlaubt allerdings
> > zugleich, eine Mehrprozessormaschine von einem Virenscanner effektiv
> > nutzen zu lassen…..
>
> NaJa, Da sehe ich einige Probleme bei. Unter anderem, daß der
> Controllierende Thread (Der weiter unter root-Rechten laufen muß, da
> er ggf. einen Benutzerwechsel auslösen muß) All diese kontrolliert.
Das musste der Virenscanner vorher auch. Bei der erstenLoesung
durfte der
Virenscanner aber alles….
> Das kann man zwar immernoch auf mehreren Prozessoren laufen lassen,
> aber ich hoffe mal das der Scanner schnell genug ist um durch die IO
> limitiert zu werden.
Liegen die Dateien auf verschiedenen, getrennt ansprechbaren
Permanentspeichersystemen, dann spart man so auch Wartezeit auf
I/O….
> Außerdem sollten die Prozessoren durch andere Dinge schon Arbeit
> haben (warum sonst mehrere Prozessoren?) Somit ist das egal.
>
Auch nachts?
> > > Bei ohne weiteres mehreren 100 Benutzern ist a) eine ungeahnte
> > > Speicehrverschwendung, b) braucht beliebig lange und c) hat einen
> > > beliebigen Overhead.
> >
> > Dies ist Unsinn. Mache Dir doch ein kleines Testprograemmchen und
> > simuliere mal dieses Problem, mit Einlesen der Datei. Ermittle die
> > tatsaechlich zusaetzlich erforderlichen Prozesswechsel…
>
> Bei einem recht neuen System (bisher nutzt die Homeverzeichnisse noch
> keiner wirklich und vor allem nicht zum Datenaustausch) sind das
> schon etwa 200. Wenn die Nutzer anfangen die Homeverzeichnisse zum
> Datenaustausch zu verwenden geht die Zahl aber schnell nach oben!
>
unguenstigenfalls: 200×0.2ms = 40ms (Deine eigenen Zahlen von
unten)…..
Damit absolut vernachlaessigbar…..
> > …und Speicherverschwendung? Textsegmente werden ueberhaupt nicht
> > kopiert, .data und .bss haben copy-on-write, und die DAteien liegen
> > ueber mmap im Adressraum des jeweiligen Prozesses?
> > WO schaffst Du es dann, Speicher zu verschwenden?
>
> Weil Du wenn Du die Aufgaben auf die verschiedenen IDs trennst für
> jeden Thread nicht nur bei der MMU einen Eintrag hast sondern auch
richtig…
> eigene Stacks, und vermutlich auch .data (es sei denn Du lagerst die
STack:richtig, .bss und .data: copy-on-write….
> Daten alle auf dem Stack). Zwar kannst Du u.U. eine gemeinsame DB der
> Signaturen nur einmal im Speicher halten, das ist aber nicht alles
> mit dem der Virenscanner arbeitet.
>
DB: mmap. Die liegt _nur_ im Virtuellen Speicher bzw. in
Dateisystempuffern….
Wir readen hier vielleicht ueber 100MB Realspeicher, also soviel, wie
ein DesktopPublishing-PRogramm oder ein dicker Mozilla braucht.
Sollte Speicher in einer grossen MAschine fehlen, ist dieser als
erstes nachzuruesten. Davon profitieren nicht nur Virenscanner….
> > > Außerdem: Was machst Du mit Dateien die auf Ihre Rechte auf 111 oder
> > > ähnlichem haben? Ersteinmal die Atribute ändern?
> > >
> > Genauso macht man das.
>
> Du willst also Deinem Virenscanner erlaube einfach so die Attribute
> von Dateien zu verändern???
Eine Tod muss ich sterben. Und Dateiattribute temporaer zu aendern,
um gerade LEseberechtigung fuer den Besitzer zuzulassen, scheint mir
ein akzeptables Risiko verglichen mit der Alternative, den
Virescanner als root laufen lassen zu muessen.
>
> > Eben, Problem der Aufgabenstellung. Ein sicherheitsrelevantes
> > Programm muss (erst recht) mit den geringstmoeglichen Rechten
> > ausgefuehrt werden koennen. Das ist hier gerade nicht gegeben. Der
> > Virenscanner wird generell mit den maximal verfuegbaren Rechten
> > ausgefuehrt.
>
> Weil er sie eben braucht. Du selbst gibst zu, daß für das scannen von
Er braucht sie i.a. nicht….Die DAteien von root sollten sich so
selten aendern, dass sie ueber auslesbare Signaturen gesichert sind
(Anti-ROotKits etc.). Postmaster sollte niemals Root sein, und Root
sollte niemals Post empfangen koennen. Die leitet man auf einen
Benutzer _ohne_ besondere REchte um….
> Files die root gehören die entsprechenden Rechte erforderlich sind.
An einem trivial vermeidbaren PRoblem sollte man keine
Entwurfsentscheidung festmachen…
> Die Frage ist also nur, ob auch der Scannende Thread die
> entsprechenden Rechte benötigt. Ich denke es macht wenig Sinn sie ihm
> nicht zu geben.
Doch. Dann kann er nur bedingt Schaden anrichten, wenn er
kompromittiert wurde.
>
> > >
> > Ja und? Frist prkatisch kein Brot, siehe oben….(Weder
> > Rechenleistung noch Speicher noch andere Ressourcen…)
>
> Na, auch ohne irgendwelche Aktionen ist das anlegen eines neuen
> Threads (Und Du mußt ihn neu anlegen, da du mit setuid nicht mehr
> zurück kannst) nicht beliebig schnell. OHNE irgendwelche Tätigkeit
> (nur anlegen eines neuen Prozesses und ID wechseln und Prozess
> beenden sowie auf sein Ende warten (Ich habe fork genommen weil
> einfacher und ich mir nicht sicher bin ob einzelne Threads des selben
> Prozesses verschiedene NutzerIDs haben können)) dauert das ganze laut
> time über 0,2ms (Ãœber 1000 gemittelt). Wenn Du jetzt noch
> Speicherzugriffe (writes), geshareten Speicher (Du mußt schließlich
> mit dem Hauptprogramm komunizieren),… hinzufügst geht das noch
> deutlich nach oben.
>
Dein eigenes Beispiel: 40ms maximal…..
> > Threads bei Linxu: sicher mehr als 1024. Hier allerdings unerheblich,
> > denn wir brauchen Prozesse mit unterschiedlicher, effektiver
> > Benutzeridentitaet.
>
> Ok, dann muß man sogar fork nehmen,
>
> > Es muessen nicht alle Kindprozesse fuer allemeoglichen Benutzer
> > gleichzeitig gestartet sein. MAn wird hier eine maximale Anzahl von
> > Prozessen vorgeben. Die Porzesse mit den am wenigsten genutzeten
> > Benutzerkennungen werden beendet, und solche mit neu erforderlichen
> > Identitaeten bei Bedarf gestartet. Absolut kein Problem.
>
> Wie gesagt: Es gibt verschiedene Möglichkeiten.
>
ABer ich schlage eine durchasu gangbare und erprobte Loesung vor….
> lrwxrwxrwx 1 root root 10 Jan 14 2005 /var/mail -> spool/mail
> s3:~ # ls -ld /var/spool/mail
> drwxrwxrwt 2 root root 4096 May 22 17:06 /var/spool/mail
>
drwxrwr-x root mail
> Sieht für mich nach 1777 aus!
>
Bei mir anders, ist Debian Sarge
> > Oje, Du hast tatsaechih relativ wenig Ahnung. DU verwechselst Threads
> > mit Prozessen,
>
> Nein verwechsle ich nicht!
> Aber im Falle einer ID kann man mit Threads effizienter arbeiten und
Gerade hier braucht man einen eigenen Prozesskontext, und Threads
werden definitionsgemaess in einem gemeinsamen KOntext
ausgefuerht….
> ob die ID thread oder Prozessweit gilt ist eine Designfrage. Mit
> NutzerIDs schlage ich mich im Normalfall nicht rum!
>
NEin. Denn genau daran haengen Berechtigungen, bzw. dren
Einschraenkung…
> > kennst keinen effektiven TReewalk usw…
>
> falsch.
> Die Frage ist nur mit welchen Nebenbedingungen Du Diene DFS machen
> möchtest. Die von mir angesprochene war mit fester NutzerID, und da
.. und eine feste EUID ist falsch, denn diese kann nur 0 (Null) sein,
um den gesamten Verzeichnisbaum durchzugehen….
> kann man nunmal nicht in jedes Verzeichniß (abgesehen davon, daß man
> u.U. auch nicht alle Datein erreicht wenn sie mit entsprechenden
> Rechten in Verzeichnissen verteilt liegen). NAtürlich kann man das
> direkt machen, hat dann aber im WC nunmal pro Datei die Notwendigkeit
> einen anderen Task (ggf. sogar neu anzulegen) mit dem Scan zu
> beauftragen.
>
JA und? Klassische Farmer-Worker-Architektur…..
Du hast bis jetzt im wesentlichen mit erhoehten Ressourcenbedaf
argumentiert, ohne diesen tatsaechlich nachweisen zu koennen. Auf
Servern opfere ich persoenlich immer ein bisschen LEsistung fuer
drastisch verbesserte Zuverlaessigkeit und Vertrauenswuerdigkeit. HA