Re: OT: Weder noch - Kasperskys Unix-Virenscanner ermöglicht …
Geschrieben von: admin in Allgemein>
> > > > Und wie sollen private DAteien von Nutzern gescannt werden? (nicht
> > > > jeder setzt og r )!
> > >
> > > Mit der Benutzeridentitaet des Eigentuemers der Dateien natuerlich.
> >
> > Hilfe!
> > Das heißt Du mußt für JEDE Datei ersteinmal die effektive UID des
> > Prozesses ändern. Und dabei mußt Du das trotzdem noch von root aus
> > machen! d.h. soviel wie Du mußt nur in Deinem Stackoverflow (bzw.
> > anderen Fehler) noch die entsprechende rücksprung Routine einbauen.
> > Oder Du startest für jede Datei einen neuen Thread.
>
> … und zwar fuer jeden Benutzer, nicht fuer jede Datei…..
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
b) Für jeden Nutzer die komplette Platte nach Datein durchsuchen auf
denen er die entsprechenden Rechte besitzt.
c) Für jede Datei (Ok nur bei jedem WEchsel der ID) einen Switch der
ID machen.
Bei ohne weiteres mehreren 100 Benutzern ist a) eine ungeahnte
Speicehrverschwendung, b) braucht beliebig lange und c) hat einen
beliebigen Overhead.
Außerdem: Was machst Du mit Dateien die auf Ihre Rechte auf 111 oder
ähnlichem haben? Ersteinmal die Atribute ändern?
> > Eben. Apache braucht root-Rechte FÜR EINE AKTION. Ein Virenscanner
> > für mehrere 10.000!
>
> Nein. Genau das darf nicht sein, dass ein Virenscanner fuer alle
> Aktionen die root-Rechte braucht. Design-Fehler, und nichts
> anderes…
Problem der Aufgabenstellung!
> > Aber eine riesige Menge an Kontext (bzw. ID)wechseln!!
> > Ich möchte nicht wissen was jede dieser Aktionen für Zeit benötigt.
> >
> Da keine “riesigen Mengen” an Kontextwechseln erforderlich sind,
> siehe oben, vergleichsweise wenig Rechenleistung.
Wie machst Du es denn dann, wenn Die IDs nicht “sauber” verteilt
genutzt werden. z.B. bei einer Webseite bei der eine Gruppe von
Leuten arbeitet und die DAteien immer 664 sind. Die Dateien gehören
verschiedenen Nutzern. Also entweder mehreere Threads gleichzeitig
nutzen (Wieviele kann der Kernel gleichzeitig?) oder doch dauernder
Nutzerwechsel.
> > > Fuer welche Gruppe muesste das Quarantaeneverzeichnis writeonly
> > > sein?
> >
> > Garnicht.
> > Charantaineverzeichniß wie /tmp Sticky 777 Sonst kannst Du es gleich
> > nach /dev/null legen.
> >
>
> WIE BITTE? Wer soll denn bitte noch lesend daraufzugreifen duerfen?
> Die Problematik ist doch eher vergleichbar mit der von
> /var/spool/mail als mit der von /tmp.
Auch bei mail darf der Besitzer lesen!
Wenn Du keine Leserechte einräumen willst dann kannst Du die DAtei
doch gleich löschen.
Und Schau Dir mal die Rechte von /var/spool/mail an!
> > > Bloedsinn…
> >
> > Wiso?
>
> Wie von Dir schon richtig festgestellt, angreifbar durch Ueberlaeufe
> von Puffern und (Ruecksprung-)Stapelspeichern.
Die Angreifbarkeit ist sehr gering, da die zu scannenden Files nicht
interpretiert werden sondern nur nach mustern gesucht wird. Ein
Pufferüberlauf ist deswegen keine Nachlässigkeit (wie in den meisten
anderen Fällen) sondern ein echter Programmierfehler (Ja ich weiß vor
einiger Zeit gab es das bei Onlinevirenscannern). Der einzige Fall
bei dem der Virenscanner einen variablen Puffer benötigt ist beim
einlesen von Dateinamen. Dies muß aber schon die Hauptinstanz machen
die ggf. überall leserechte hat.
> > So pauschal kann man das nicht sagen!
> Doch, leider….
eben nicht! s.u.
> > Es ist zwar richtig, daß einen neue Lücke eingebaut wurde, aber dafür
> > wurden auch eine Menge anderer geschlossen (nämlich die Viren,
> > Trojaner etc.) Ob das Netto die Sicherheit erniedrigt hat ist da eine
> Nun, wie wurde denn die Sicherheit erhoeht?
>
> Welche beschreibbaren Verzeichnisse, wie /home, /tmp/, /var, sind
> denn im Produktivbetreieb mit exec,dev,suid montiert?
wiso dev? wiso suid?
/tmp ist 1777 (Sticky ist hier die Lösung des Problems!)
/var/spool/mail ist i.a. auch 1777 wenn ich mich recht entsinne (habe
auf maildir umgestellt)
> > noch offene Frage. Vor allem weil zumindest auf den ersten Blick
> > keine übermäßige Gefahr bestand (”nur” DOS).
> Symlink-Attacken lassen sich zu weitaus mehr als zu DOS benutzen….
i.A. Ja, aber wenn Du das was geschrieben wird nicht kontrollieren
kannst (bzw. nur sehr begrenzt beeinflussen kannst) dann kannst Du
eben nicht viel mehr damit anfangen.
Tschau
Stm