Wer wireshark zur Netzwerkanalyse verwenden möchte und als normaler, nicht-privilegierter Benutzer startet, wird beim Versuch ein "Capture Interface" fest zu legen bemerken, daß keine Netzwerkgeräte zur Auswahl stehen.
Das Problem liegt darin, daß die Anwendung
/usr/bin/dumpcap
mit Rootrechten laufen muss um Zugriff auf die Netzwerkinterfaces zu haben.
Als "einfachste" Lösung kann man wireshark als root starten, was aber den Nachteil hat, daß dann eben die gesamte Anwendung als root läuft statt nur einer der "Hilfsanwendungen", die diese Zugriffsrechte wirklich braucht.
Nun würde man sagen "Na wenn das das einzige Problem ist, dann setzt man einfach mit chmod das SUID-bit und alles ist bestens", aber diese Methode hat zwei entscheidende Nachteile.
1. Nun kann _jeder_ Nutzer uneingeschränkt wireshark verwenden, was z.B. auf Multiusersystemen nicht unbedingt erwünscht ist.
2. Nach jedem Sicherheitsupdate (und für wireshark gab/gibt es immer wieder Updates) muss man das Spielchen wiederholen.
Im folgenden Tutorial will ich einen schnellen, einfachen und auch sicheren Weg zeigen, wie man dieses Problem so lösen kann, daß 1. und 2. keine Rolle mehr spielen.
Das Prinzip greift auf SuSEconfig zurück und setzt explizit Zugriffsrechte für die Gruppe "trusted", die z.B. auch dann Verwendung findet, wenn man "sichere" Zugriffsrechte als default-Einstellungen wählt (YaST => Sicherheit und Benutzer).
Das Ganze ist schnell erledigt.
A) Der/die entsprechende(n) Nutzer über "YaST => Sicherheit und Benutzer => Benutzer- und Gruppenverwaltung" zur Gruppe "trusted" hinzufügen.
B) Als root eine Datei
/etc/permissions.d/wireshark
mit folgendem Inhalt anlegen:
C) Als root
aufrufen und das wars auch schon.
Nach dem nächsten Login des entsprechenden Users sind die Einstellungen aktiv und /usr/bin/dumpcap läuft zwar immer mit SUID-Bit, kann aber nur von Nutzern aufgerufen werden, die der Gruppe "trusted" angehören.
Wer seine Online Updates über YaST macht wird keine weiteren Probleme damit haben, da YaST nach jeder Installation/Update von Paketen automatisch SuSEconfig aufruft, wer smart/zypper/apt verwendet, kann dies anhand der Ausgabe kontrollieren und im Zweifelsfall direkt nach einem Update SuSEconfig als root ausfrufen.
Anmerkung:
Der entsprechende User darf nach dieser Änderung _alle_ Anwendungen, die nur der "trusted"-Gruppe vorbehalten sind, aufrufen.
Bei den default-Einstellungen zur lokalen Sicherheit ("permissions.easy") spielt dies keine Rolle, da dort nicht auf diese Gruppe als einschränkende Maßnahme zurückgegriffen wird, wer jedoch "permissions.secure" verwendet und das Ganze noch weiter einschränken und nur Zugriff auf wireshark erlauben möchte, kann dafür eine eigene Gruppe z.B. mit dem Namen "wireshark" einrichten, den/die gewünschten Nutzer dieser Gruppe hinzufügen und den Eintrag entsprechend auf:
ändern.
Diese Methode kann natürlich auch zur Einschränkung anderer Anwendungen für eine bestimmte Gruppe genutzt werden, egal ob dabei ein SUID-Bit notwendig ist oder nicht, das Prinzip ist allgemeingültig und die Einträge in einer entsprechenden /etc/permissions.d/<Irgendwas>-Datei sorgen dafür, daß diese Rechte auch erhalten bleiben.
Greetz,
RM
Das Problem liegt darin, daß die Anwendung
/usr/bin/dumpcap
mit Rootrechten laufen muss um Zugriff auf die Netzwerkinterfaces zu haben.
Als "einfachste" Lösung kann man wireshark als root starten, was aber den Nachteil hat, daß dann eben die gesamte Anwendung als root läuft statt nur einer der "Hilfsanwendungen", die diese Zugriffsrechte wirklich braucht.
Nun würde man sagen "Na wenn das das einzige Problem ist, dann setzt man einfach mit chmod das SUID-bit und alles ist bestens", aber diese Methode hat zwei entscheidende Nachteile.
1. Nun kann _jeder_ Nutzer uneingeschränkt wireshark verwenden, was z.B. auf Multiusersystemen nicht unbedingt erwünscht ist.
2. Nach jedem Sicherheitsupdate (und für wireshark gab/gibt es immer wieder Updates) muss man das Spielchen wiederholen.
Im folgenden Tutorial will ich einen schnellen, einfachen und auch sicheren Weg zeigen, wie man dieses Problem so lösen kann, daß 1. und 2. keine Rolle mehr spielen.
Das Prinzip greift auf SuSEconfig zurück und setzt explizit Zugriffsrechte für die Gruppe "trusted", die z.B. auch dann Verwendung findet, wenn man "sichere" Zugriffsrechte als default-Einstellungen wählt (YaST => Sicherheit und Benutzer).
Das Ganze ist schnell erledigt.
A) Der/die entsprechende(n) Nutzer über "YaST => Sicherheit und Benutzer => Benutzer- und Gruppenverwaltung" zur Gruppe "trusted" hinzufügen.
B) Als root eine Datei
/etc/permissions.d/wireshark
mit folgendem Inhalt anlegen:
Code:
/usr/bin/dumpcap root:trusted 4750
Code:
SuSEconfig --module permissionsNach dem nächsten Login des entsprechenden Users sind die Einstellungen aktiv und /usr/bin/dumpcap läuft zwar immer mit SUID-Bit, kann aber nur von Nutzern aufgerufen werden, die der Gruppe "trusted" angehören.
Wer seine Online Updates über YaST macht wird keine weiteren Probleme damit haben, da YaST nach jeder Installation/Update von Paketen automatisch SuSEconfig aufruft, wer smart/zypper/apt verwendet, kann dies anhand der Ausgabe kontrollieren und im Zweifelsfall direkt nach einem Update SuSEconfig als root ausfrufen.
Anmerkung:
Der entsprechende User darf nach dieser Änderung _alle_ Anwendungen, die nur der "trusted"-Gruppe vorbehalten sind, aufrufen.
Bei den default-Einstellungen zur lokalen Sicherheit ("permissions.easy") spielt dies keine Rolle, da dort nicht auf diese Gruppe als einschränkende Maßnahme zurückgegriffen wird, wer jedoch "permissions.secure" verwendet und das Ganze noch weiter einschränken und nur Zugriff auf wireshark erlauben möchte, kann dafür eine eigene Gruppe z.B. mit dem Namen "wireshark" einrichten, den/die gewünschten Nutzer dieser Gruppe hinzufügen und den Eintrag entsprechend auf:
Code:
/usr/bin/dumpcap root:wireshark 4750Diese Methode kann natürlich auch zur Einschränkung anderer Anwendungen für eine bestimmte Gruppe genutzt werden, egal ob dabei ein SUID-Bit notwendig ist oder nicht, das Prinzip ist allgemeingültig und die Einträge in einer entsprechenden /etc/permissions.d/<Irgendwas>-Datei sorgen dafür, daß diese Rechte auch erhalten bleiben.
Greetz,
RM