|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Sunday 09. April 2006, 21:59 MEW (#1)
|
|
|
|
|
Anm. von Venty: "Das 'Problem' mit den Benutzerrechten unter Linux bleibt dadurch aber weiterhin für einen potentiellen Virus bestehen." Welches Problem? Ich habe hier nur ein Solaris, aber unter Linux gibt es auch eine Implementierung von setfacl (1) - modify the Access Control List (ACL) for a file or files oder meinst du Least Privilege (was meines erachtens sehr gut unter UNIX funktioniert, im Gegensatz zu Win)?
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 10. April 2006, 07:19 MEW (#5)
|
|
|
|
|
na er wird wohl least privilege meinen. das ist wohl wenn es richtig angewendet wird einen wurm/virii der beste virenschutz mit. virenscanner sind in meinen augen nur patchwork weil das system (win) zu doof war eine infektion einzudaemmen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Richtig, genau das habe ich gemeint. Für einen Virus stellt das (richtig angewandte) Rechtesystem eines Unix ein ziemliches 'Problem' dar.
--
Das Recht auf die Privatkopie existiert!
|
|
|
|
|
|
|
News? (Score:2, Informativ)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 09. April 2006, 22:34 MEW (#3)
|
|
|
|
|
das wusste ich nicht. Ich vertraute LinuxToday, dass sie mir aktuelle News bieten, was nicht der Fall war.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 10. April 2006, 01:56 MEW (#4)
|
|
|
|
|
Plattformunabhaengig ist ja nunmal leicht uebertrieben. Mit einer interpretierten Sprache kaeme man dem ein Stueck weiter, aber derzeit gibt es noch ein paar Plattformen, die nicht notwendigerweise eine x86-CPU haben. System-Calls sind ja auch nicht plattformunabhaengig (hoechstens im Source), d.h. ein Linux-ELF laeuft noch lange nicht unter einem anderen Unix, solange dies keinen Emulation-Layer bietet.
Daher wie gesagt: plattformunabhaengig != laeuft auf mehr als einer Plattform.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich wuerde den Begriff 'Plattform' am ehesten mit CHOST erklaeren:
x86_64-linux-gnu ist eine Plattform
i686-linux-gnu eine andere
i686-netbsd-gnu nochmal eine andere
usw...
|
|
|
|
|
|
|
|
|
|
|
|
|
Das der Befall von ausführbaren Dateien nicht sehr kritisch ist, ist ja klar. Ich hab über Planet Debian nen guten Artikel gefunden.
Was ich seltsam finde: Diese E-Mailwürmer sind doch ein Problem weil sie das Netz so überlasten, aber bisher scheint noch niemand Evolution oder so ausgenutzt zu haben. Den Netzwerkzugriff verbietet ja kein Rechtesystem auf keinem Unix oder?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Den Netzwerkzugriff verbietet ja kein Rechtesystem auf keinem Unix oder?
Unixe vielleicht nicht.
Linux seit 2.2 kennt Capabilities
(capabilities(7), capset(2), capget(2), usw.) mit denen man fein Permissions bezgl. Ressourcen vergeben kann.
Das ist die Infrastruktur (Vorstufe) fuer SE-Linux und andere ACL-basierte Rechtesysteme fuer Prozesse.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 11. April 2006, 14:12 MEW (#12)
|
|
|
|
|
Das man den Netzwerkzugriff nicht so ohne weiteres Einschraenken kann, fand ich ehrlich gesagt schon immer ziemlich kurios. Zumindest in den letzten 10 Jahren ist das Internet doch die Hauptgefahr fuer die Sicherheit eines jeden Rechners geworden. Es liegt wohl aber einfach daran, dass es nichts zu chmodden gibt. Im Gegensatz zu den meisten Geraeten, sind Netzwerkgeraete unter Unix ja eben keine Dateien.
Andererseits waere der Zugriff pro Nutzer in den meisten Situationen wenig sinnvoll. Soetwas will man, vor allem feiner granuliert eher pro Anwendung regeln. Dafuer gibt es ja Systrace. Allerdings funktioniert das nur unter NetBSD und OpenBSD einwandfrei. Auch wenn es unter Linux sonst Support fuer jeden Scheiss gibt, gibt es dort nach Jahren noch immer keinen Systrace-Support im Kernel. Es gibt eine ptrace-basierte Variante, aber die ist eher als "Trial-Version" zu verstehen, da sie durch race-conditions etc. ausgehebelt werden kann.
|
|
|
|
|
