Hallo, nach der Installation von Opensuse 13.2 geht der "RFID komfort" nicht mehr. "Moneyplex" zeigt keinen PC-SC-Treiber an, "Cyberjack" meldet: "3 99 5 0 final.SP05 SuSE 13.2 Linux 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 Benutzer "..." ist Mitglied der Gruppe "cyberjack" Service is not available". Weitere Ausgaben: # killall pcscd pcscd: Kein Prozess gefunden /usr/sbin/pcscd-f-a-d 00000000 debuglog.c:295:DebugLogSetLevel() debug level=debug 00000126 configfile.l:286:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000034 configfile.l:298:DBGetReaderListDir() Skipping non regular file: . 00000011 configfile.l:298:DBGetReaderListDir() Skipping non regular file: .. 00000010 configfile.l:339:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/reader.conf 00000071 pcscdaemon.c:571:main() pcsc-lite1.8.11 daemon ready. 00000760 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 00000094 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 00000090 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x04A9, PID: 0x221C, path: /dev/bus/usb/003/002 00000095 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 00000084 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1A40, PID: 0x0101, path: /dev/bus/usb/003/003 00000107 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0003, path: /dev/bus/usb/004/001 00000104 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 00000079 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 00000087 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/001/002 00000088 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x24AE, PID: 0x2001, path: /dev/bus/usb/001/003 00000083 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x24AE, PID: 0x2001, path: /dev/bus/usb/001/003 00000085 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/001/002 00000108 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 00000082 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 00000095 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/002/002 00000089 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x03F0, PID: 0x1017, path: /dev/bus/usb/002/003 00000087 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/002/002 00000089 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x046D, PID: 0x0A0C, path: /dev/bus/usb/002/004 00000086 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x046D, PID: 0x0A0C, path: /dev/bus/usb/002/004 00000088 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x046D, PID: 0x0A0C, path: /dev/bus/usb/002/004 00000086 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x046D, PID: 0x0A0C, path: /dev/bus/usb/002/004 00000083 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/002/002 00000087 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x05E3, PID: 0x0608, path: /dev/bus/usb/002/005 00000093 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x0C4B, PID: 0x0501, path: /dev/bus/usb/002/006 00000028 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x0C4B, PID: 0x0501, path: /dev/bus/usb/002/006 00000010 hotplug_libudev.c:347:HPAddDevice() Adding USB device: REINER SCT cyberJack RFID komfort 00000040 readerfactory.c:1015:RFInitializeReader() Attempting startup of REINER SCT cyberJack RFID komfort(3284189382) 00 00 using /usr/lib64/readers/libifd-cyberjack.bundle/Contents/Linux/libifd-cyberjack.so CYBERJACK: Started 00001699 readerfactory.c:900:RFBindFunctions() Loading IFDHandler 3.0 00014083 readerfactory.c:353:RFAddReader() Using the pcscd polling thread 00000441 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x05E3, PID: 0x0608, path: /dev/bus/usb/002/005 00000091 hotplug_libudev.c:295:get_driver() Looking for a driverfor VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/002/002 00000042 readerfactory.c:1356:RFWaitForReaderInit() Waiting initfor reader: REINER SCT cyberJack RFID komfort(3284189382) 00 00 00010100 readerfactory.c:1356:RFWaitForReaderInit() Waiting initfor reader: REINER SCT cyberJack RFID komfort(3284189382) 00 00 00010110 readerfactory.c:1356:RFWaitForReaderInit() Waiting initfor reader: REINER SCT cyberJack RFID komfort(3284189382) 00 00 00010130 readerfactory.c:1356:RFWaitForReaderInit() Waiting initfor reader: REINER SCT cyberJack RFID komfort(3284189382) 00 00 00003898 eventhandler.c:292:EHStatusHandlerThread() powerState: POWER_STATE_POWERED 00000028 Card ATR: 3B FF18 00 FF81 31 FE45 65 63 11 08 66 01 56 00 11 62 20 03 12 06 20 59 00400906 eventhandler.c:481:EHStatusHandlerThread() powerState: POWER_STATE_UNPOWERED 45790873 winscard_msg_srv.c:256:ProcessEventsServer() Common channel packet arrival 00000033 winscard_msg_srv.c:268:ProcessEventsServer() ProcessCommonChannelRequest detects: 14 00000005 pcscdaemon.c:137:SVCServiceRunLoop() Anew context thread creationis requested: 14 00008551 auth.c:136:IsClientAuthorized() Process 29569 (user: 1000) is NOT authorizedfor action: access_pcsc 00000138 winscard_svc.c:329:ContextThread() Rejected unauthorized PC/SC client Hat jemand eine Information, was in Opensuse geändert worden ist? Viele Grüße Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.11.2014 um 15:53 schrieb Jürgen Heiler:
Hallo,
nach der Installation von Opensuse 13.2 geht der "RFID komfort" nicht mehr.
"Moneyplex" zeigt keinen PC-SC-Treiber an, "Cyberjack" meldet: "3 99 5 0 final.SP05 SuSE 13.2 Linux 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 Benutzer "..." ist Mitglied der Gruppe "cyberjack" Service is not available". Weitere Ausgaben: ----- snip ---- creationis requested: 14 00008551 auth.c:136:IsClientAuthorized() Process 29569 (user: 1000) is NOT authorizedfor action: access_pcsc 00000138 winscard_svc.c:329:ContextThread() Rejected unauthorized PC/SC client
Hat jemand eine Information, was in Opensuse geändert worden ist?
Viele Grüße Jürgen
Hi, ja, da haben es die Sicherheitsleute von openSUSE etwas übertrieben. Hintergrund: Upstream hat Unterstützung für policy kit in pcscd eingebaut. Die default-Einstellung in openSUSE lautet: Nur root darf noch zugreifen. Die Patches für das Problem sind seit letzter Woche fertig, haben es aber wohl noch nicht in die Update-Repos geschafft. Inzwischen heißt es policy-kit-rule-Dateien häcken. In /etc/polkit-1/rules.d gibt es die Datei 90-default-privs.rules. Da drin 2 Einträge: 'org.debian.pcsc-lite.access_card': [ 'auth_admin', 'auth_admin', 'auth_admin' ], ... 'org.debian.pcsc-lite.access_pcsc': [ 'auth_admin', 'auth_admin', 'auth_admin' ], ändern nach: 'org.debian.pcsc-lite.access_card': [ 'auth_admin', 'auth_admin', 'yes' ], ... 'org.debian.pcsc-lite.access_pcsc': [ 'auth_admin', 'auth_admin', 'yes' ], Der policy kit-Daemon muss dann noch die neue Konfiguration lesen (einfach neu starten), und dann sollte es wieder gehen. Es gibt da noch in /etc einige Dateien, wo die Vorgaben für diese Regeln drin stehen. Ob man die auch anpassen sollte, damit die alten Einstellungen nicht wieder generiert werden, weiß ich nicht: polkit-default-privs.restrictive polkit-default-privs.standard Gruß, Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.11.2014 um 18:41 schrieb Hendrik Woltersdorf:
Am 06.11.2014 um 15:53 schrieb Jürgen Heiler:
Hallo,
nach der Installation von Opensuse 13.2 geht der "RFID komfort" nicht mehr.
"Moneyplex" zeigt keinen PC-SC-Treiber an, "Cyberjack" meldet: "3 99 5 0 final.SP05 SuSE 13.2 Linux 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 Benutzer "..." ist Mitglied der Gruppe "cyberjack" Service is not available". Weitere Ausgaben: ----- snip ---- creationis requested: 14 00008551 auth.c:136:IsClientAuthorized() Process 29569 (user: 1000) is NOT authorizedfor action: access_pcsc 00000138 winscard_svc.c:329:ContextThread() Rejected unauthorized PC/SC client
Hat jemand eine Information, was in Opensuse geändert worden ist?
Viele Grüße Jürgen
Hi,
ja, da haben es die Sicherheitsleute von openSUSE etwas übertrieben. Hintergrund: Upstream hat Unterstützung für policy kit in pcscd eingebaut. Die default-Einstellung in openSUSE lautet: Nur root darf noch zugreifen.
Die Patches für das Problem sind seit letzter Woche fertig, haben es aber wohl noch nicht in die Update-Repos geschafft.
Inzwischen heißt es policy-kit-rule-Dateien häcken.
In /etc/polkit-1/rules.d gibt es die Datei 90-default-privs.rules.
Da drin 2 Einträge:
'org.debian.pcsc-lite.access_card': [ 'auth_admin', 'auth_admin', 'auth_admin' ], ... 'org.debian.pcsc-lite.access_pcsc': [ 'auth_admin', 'auth_admin', 'auth_admin' ],
ändern nach:
'org.debian.pcsc-lite.access_card': [ 'auth_admin', 'auth_admin', 'yes' ], ... 'org.debian.pcsc-lite.access_pcsc': [ 'auth_admin', 'auth_admin', 'yes' ],
Der policy kit-Daemon muss dann noch die neue Konfiguration lesen (einfach neu starten), und dann sollte es wieder gehen.
Es gibt da noch in /etc einige Dateien, wo die Vorgaben für diese Regeln drin stehen. Ob man die auch anpassen sollte, damit die alten Einstellungen nicht wieder generiert werden, weiß ich nicht:
polkit-default-privs.restrictive polkit-default-privs.standard
Gruß, Hendrik
Hallo Herndrik, bis dahin besten Dank. Es scheint aber noch ein Problem zu geben, da ich pcscd nach jedem Hochfahren neu starten muss: # killall pcscd pcscd: Kein Prozess gefunden linux-cy54:/home/heiler # /usr/sbin/pcscd -f -a -d 00000000 debuglog.c:295:DebugLogSetLevel() debug level=debug 00000050 utils.c:87:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory 00000075 configfile.l:286:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000015 configfile.l:298:DBGetReaderListDir() Skipping non regular file: . 00000004 configfile.l:298:DBGetReaderListDir() Skipping non regular file: .. 00000006 configfile.l:339:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/reader.conf 00000083 pcscdaemon.c:571:main() pcsc-lite 1.8.11 daemon ready. Viele Grüße Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.11.2014 um 10:05 schrieb Jürgen Heiler:
bis dahin besten Dank. Es scheint aber noch ein Problem zu geben, da ich pcscd nach jedem Hochfahren neu starten muss:
# killall pcscd pcscd: Kein Prozess gefunden linux-cy54:/home/heiler # /usr/sbin/pcscd -f -a -d 00000000 debuglog.c:295:DebugLogSetLevel() debug level=debug 00000050 utils.c:87:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory 00000075 configfile.l:286:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000015 configfile.l:298:DBGetReaderListDir() Skipping non regular file: . 00000004 configfile.l:298:DBGetReaderListDir() Skipping non regular file: .. 00000006 configfile.l:339:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/reader.conf 00000083 pcscdaemon.c:571:main() pcsc-lite 1.8.11 daemon ready.
Inwiefern ist das ein Fehler? pcscd wird nicht beim Booten gestartet, sondern aktiviert, wenn ein Zugriff auf einen Kartenleser erfolgt. Könnte das vielleicht eine Erklärung sein? Wolfgang -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.11.2014 um 15:11 schrieb Wolfgang Rosenauer:
Am 07.11.2014 um 10:05 schrieb Jürgen Heiler:
bis dahin besten Dank. Es scheint aber noch ein Problem zu geben, da ich pcscd nach jedem Hochfahren neu starten muss:
# killall pcscd pcscd: Kein Prozess gefunden linux-cy54:/home/heiler # /usr/sbin/pcscd -f -a -d 00000000 debuglog.c:295:DebugLogSetLevel() debug level=debug 00000050 utils.c:87:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory 00000075 configfile.l:286:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000015 configfile.l:298:DBGetReaderListDir() Skipping non regular file: . 00000004 configfile.l:298:DBGetReaderListDir() Skipping non regular file: .. 00000006 configfile.l:339:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/reader.conf 00000083 pcscdaemon.c:571:main() pcsc-lite 1.8.11 daemon ready.
Inwiefern ist das ein Fehler? pcscd wird nicht beim Booten gestartet, sondern aktiviert, wenn ein Zugriff auf einen Kartenleser erfolgt. Könnte das vielleicht eine Erklärung sein?
Wolfgang
War aber in Opensuse 13.1 anders, so sieht Moneyplex den Leser nicht und kann nicht auf ihn zugreifen. Viele Grüße Jürgen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.11.2014 um 16:15 schrieb Jürgen Heiler:
Am 07.11.2014 um 15:11 schrieb Wolfgang Rosenauer:
Am 07.11.2014 um 10:05 schrieb Jürgen Heiler:
bis dahin besten Dank. Es scheint aber noch ein Problem zu geben, da ich pcscd nach jedem Hochfahren neu starten muss:
# killall pcscd pcscd: Kein Prozess gefunden linux-cy54:/home/heiler # /usr/sbin/pcscd -f -a -d 00000000 debuglog.c:295:DebugLogSetLevel() debug level=debug 00000050 utils.c:87:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory 00000075 configfile.l:286:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000015 configfile.l:298:DBGetReaderListDir() Skipping non regular file: . 00000004 configfile.l:298:DBGetReaderListDir() Skipping non regular file: .. 00000006 configfile.l:339:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/reader.conf 00000083 pcscdaemon.c:571:main() pcsc-lite 1.8.11 daemon ready.
Inwiefern ist das ein Fehler? pcscd wird nicht beim Booten gestartet, sondern aktiviert, wenn ein Zugriff auf einen Kartenleser erfolgt. Könnte das vielleicht eine Erklärung sein?
Wolfgang
War aber in Opensuse 13.1 anders, so sieht Moneyplex den Leser nicht und kann nicht auf ihn zugreifen.
Hmm, es gab einen Fehler im aktuellen 13.2 Paket, der demnächst gepatcht wird. Evtl. hat der damit zu tun. Letzendlich fehlt bei einer Neuinstallation von 13.2 die Datei /etc/sysconfig/pcscd, worüber das System dann stolpert. Siehe http://bugzilla.opensuse.org/show_bug.cgi?id=900115 Ansonsten müsste es jedoch funktionieren (bis auf polkit, was auch in dem Bug behandelt wird). Ich verwende selbst moneyplex mit pcsc-lite/cyberjack auf 13.2 erfolgreich. Unter Anwendung der Fixes aus obigem Bug. Wolfgang -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.11.2014 um 18:41 schrieb Hendrik Woltersdorf:
Am 06.11.2014 um 15:53 schrieb Jürgen Heiler:
Hallo,
nach der Installation von Opensuse 13.2 geht der "RFID komfort" nicht mehr.
"Moneyplex" zeigt keinen PC-SC-Treiber an, "Cyberjack" meldet: "3 99 5 0 final.SP05 SuSE 13.2 Linux 3.16.6-2-desktop #1 SMP PREEMPT Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 Benutzer "..." ist Mitglied der Gruppe "cyberjack" Service is not available". Weitere Ausgaben: ----- snip ---- creationis requested: 14 00008551 auth.c:136:IsClientAuthorized() Process 29569 (user: 1000) is NOT authorizedfor action: access_pcsc 00000138 winscard_svc.c:329:ContextThread() Rejected unauthorized PC/SC client
Hat jemand eine Information, was in Opensuse geändert worden ist?
Viele Grüße Jürgen
Hi,
ja, da haben es die Sicherheitsleute von openSUSE etwas übertrieben. Hintergrund: Upstream hat Unterstützung für policy kit in pcscd eingebaut. Die default-Einstellung in openSUSE lautet: Nur root darf noch zugreifen.
Die Patches für das Problem sind seit letzter Woche fertig, haben es aber wohl noch nicht in die Update-Repos geschafft.
Inzwischen heißt es policy-kit-rule-Dateien häcken.
Reicht es nicht, die Permissions-Einstellung im YaST auf "Easy" zu setzen? Erinnere mich, dass das in der 12.3 genau so ging in Bezug auf das Einbinden (Mounten) externer Speicher. Das ging zunächst nicht, weil die Permissions-Einstellung auf dem mittleren Level (Name fällt mir gerade nicht ein -- jedenfalls zw. "Easy" und "Paranoid") standen.
In /etc/polkit-1/rules.d gibt es die Datei 90-default-privs.rules.
Da drin 2 Einträge:
'org.debian.pcsc-lite.access_card': [ 'auth_admin', 'auth_admin', 'auth_admin' ], ... 'org.debian.pcsc-lite.access_pcsc': [ 'auth_admin', 'auth_admin', 'auth_admin' ],
ändern nach:
'org.debian.pcsc-lite.access_card': [ 'auth_admin', 'auth_admin', 'yes' ], ... 'org.debian.pcsc-lite.access_pcsc': [ 'auth_admin', 'auth_admin', 'yes' ],
So kann man die Rechte natürlich feiner einstellen.
Der policy kit-Daemon muss dann noch die neue Konfiguration lesen (einfach neu starten), und dann sollte es wieder gehen.
Es gibt da noch in /etc einige Dateien, wo die Vorgaben für diese Regeln drin stehen. Ob man die auch anpassen sollte, damit die alten Einstellungen nicht wieder generiert werden, weiß ich nicht:
polkit-default-privs.restrictive
Paranoid?
polkit-default-privs.standard
Die mittlere Permissions-Einstellung? Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.11.2014 um 15:27 schrieb Thomas Michalka:
Am 06.11.2014 um 18:41 schrieb Hendrik Woltersdorf:
Am 06.11.2014 um 15:53 schrieb Jürgen Heiler:
Hallo,
Inzwischen heißt es policy-kit-rule-Dateien häcken.
Reicht es nicht, die Permissions-Einstellung im YaST auf "Easy" zu setzen? Erinnere mich, dass das in der 12.3 genau so ging in Bezug auf das Einbinden (Mounten) externer Speicher. Das ging zunächst nicht, weil die Permissions-Einstellung auf dem mittleren Level (Name fällt mir gerade nicht ein -- jedenfalls zw. "Easy" und "Paranoid") standen.
polkit-default-privs.restrictive
Paranoid?
polkit-default-privs.standard
Die mittlere Permissions-Einstellung?
Gruß, Tom
Und polkit-default-privs.local müsste demnach "Easy" sein. Könnte funktionieren, aber vielleicht will man ja nicht gleich alle Sicherungen rausdrehen, nur weil ein Programm Probleme hat. Gruß, Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.11.2014 um 17:51 schrieb Hendrik Woltersdorf:
Am 07.11.2014 um 15:27 schrieb Thomas Michalka:
Am 06.11.2014 um 18:41 schrieb Hendrik Woltersdorf:
Am 06.11.2014 um 15:53 schrieb Jürgen Heiler:
Hallo,
Inzwischen heißt es policy-kit-rule-Dateien häcken.
Reicht es nicht, die Permissions-Einstellung im YaST auf "Easy" zu setzen? Erinnere mich, dass das in der 12.3 genau so ging in Bezug auf das Einbinden (Mounten) externer Speicher. Das ging zunächst nicht, weil die Permissions-Einstellung auf dem mittleren Level (Name fällt mir gerade nicht ein -- jedenfalls zw. "Easy" und "Paranoid") standen.
polkit-default-privs.restrictive
Paranoid?
polkit-default-privs.standard
Die mittlere Permissions-Einstellung?
Gruß, Tom
Und polkit-default-privs.local müsste demnach "Easy" sein.
Das muss ich bald mal untersuchen, weil ich nach diesen Dateien damals gesucht, sie aber nicht gefunden habe.
Könnte funktionieren, aber vielleicht will man ja nicht gleich alle Sicherungen rausdrehen, nur weil ein Programm Probleme hat.
Stimmt schon. Ist aber nicht so kritisch, wenn man die Maschine so gut wie nur für sich hat, will heißen, dass sie keine Dienste im LAN anbietet. Übrigens: die mittlere Stufe heißt "Secure" und es handelt sich konkret um die grundlegende Einstellung der _File-Permissions_. Apropos Zugriffsrechte: es gibt IMHO dabei einen ziemlichen Wildwuchs: - klass. Unix-Rechte - ACLs - Polkit - Apparmor - ... Und an all den benannten Rechtesystemen musste ich schon herumschrauben (Apparmor sogar abschalten), z.B. um folgende Dienste auf einem Server überhaupt nutzbar zu bekommen: - Dovecot - Samba - Mounten von Speichersticks und CDROMs durch Benutzer Ich finde, man kann es mit der Sicherheit auch übertreiben. Was nützt einem eine hohe Sicherheit, wenn man selbst im LAN den einen oder anderen Dienst erst mal gar nicht nutzen kann. Benutzer, die sich mit der Administration nicht so gut auskennen, sind damit aufgeschmissen. Wohlgemerkt: ich rede nur vom eigenen LAN. Beim Übergang vom LAN ins Internet am Router sehe ich das andersherum: zunächst alles für Anfragen von außen unerreichbar machen, danach nur die Löchlein bohren, die man unbedingt braucht. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.11.2014 um 19:05 schrieb Thomas Michalka:
Ich finde, man kann es mit der Sicherheit auch übertreiben. Was nützt einem eine hohe Sicherheit, wenn man selbst im LAN den einen oder anderen Dienst erst mal gar nicht nutzen kann. Doch, man kann nicht genug Sicherheit haben. Die Banditen schlafen nicht, wir haben nur "Glück" weil Linux auf Desktops nicht so verbreitet ist und nicht zu vergessen, Linux ist ein offenes System, wo viele Programmierer zügiger als Microsoft reagieren. Benutzer, die sich mit der Administration nicht so gut auskennen, sind damit aufgeschmissen. Wohlgemerkt: ich rede nur vom eigenen LAN. In dem Punkt geb ich eingeschrängt Recht. Gerade deshalb ist es gut, das die Sicherheit einen hohen Stellenswert hat, weil ich als einfacher Nutzer gar keine Ahnung hätte wo ich überall Tore und Türen zu machen müßte. Aber, die Entwickler könnten ein bißchen von Windows Firewalls abgucken und Abfragen einbauen. Will ein Programm raustelefonieren, sollte eine Abfrage erscheinen.
Gruß Hugo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 08.11.2014 um 09:24 schrieb Hugo Egon Maurer:
Am 07.11.2014 um 19:05 schrieb Thomas Michalka:
Ich finde, man kann es mit der Sicherheit auch übertreiben. Was nützt einem eine hohe Sicherheit, wenn man selbst im LAN den einen oder anderen Dienst erst mal gar nicht nutzen kann? Doch, man kann nicht genug Sicherheit haben.
Also totale Sicherheit. Dumm ist nur, dass man sich dann in den weltweiten Netzen überhaupt nicht mehr bewegen kann. Das ist unrealistisch, was du an folgender Analogie unschwer erkennen wirst: Wenn Du als Mieter vor Deine Haustür gehst, kann Dich ein Dachziegel treffen. Wenn das nicht passiert, hast Du Glück gehabt, weil sich trotz mangelnder Sorgfalt Deines Vermieters trotzdem gerade kein Ziegel gelöst hat. Wenn Du dann an der Gehsteigkante stehst, kann Dich ein Außenspiegel eines Omnibus umnieten, wenn das nicht passiert, kannst Du beim Versuch, die Straße zu überqueren, von einem Auto erfasst und totgefahren werden. Willst Du angesichts dieser Risiken (AKA relative Unsicherheit) Deine Wohnung oder Dein Haus denn nicht mehr verlassen? Was ist daran zu erkennen? Im normalen Alltag fordert auch niemand die totale Sicherheit, wodurch wir, nebenbei gesagt, unsere Freiheit verlieren würden. Wollen wir das? Wollen wir also wirklich totale Sicherheit in den Netzen, sogar innerhalb unseres eigenen LAN? Ich jedenfalls nicht, weil mich dann mein LAN und meine Rechnersysteme mehr behindern als mir nützen würden. Ich will deshalb eine vernünftige Balance zwischen Sicherheit und Freiheit, sowohl im Alltagsleben als auch in Netzwerken. Übrigens ging es mir in meinem Posting speziell um File-Permissions, die ja nur den lokalen Rechner betreffen, und der gehört sowieso ganz mir -- was soll ich mir also unnötige, innere Hürden aufbauen?
Die Banditen schlafen nicht, wir haben nur "Glück" weil Linux auf Desktops nicht so verbreitet ist und nicht zu vergessen, Linux ist ein offenes System, wo viele Programmierer zügiger als Microsoft reagieren.
Sicher stimmt es, dass man bei einer weitaus größeren Benutzerbasis mit deutlich mehr unbedarften Menschen rechnen und daher mehr einfach bedienbare Vorkehrungen für Sicherheit einbauen müsste. Aber muss man deshalb nach der Systeminstallation gleich alle einschaltet haben?
Benutzer, die sich mit der Administration nicht so gut auskennen, sind damit aufgeschmissen. Wohlgemerkt: ich rede nur vom eigenen LAN. In dem Punkt geb ich eingeschrängt Recht. Gerade deshalb ist es gut, das die Sicherheit einen hohen Stellenswert hat, weil ich als einfacher Nutzer gar keine Ahnung hätte wo ich überall Tore und Türen zu machen müßte.
Du drehst mein Argument gegen mich um: ich meinte es so, dass bei zu vielen Sicherheitshürden unbedarfte Benutzer dann selbst auf dem eigenen Rechner bestimmte Dienste nicht vernünftig nutzen können. Was nützt einem ein nahezu völlig sicherer Rechner, wenn man elementare Dinge, wie das Einbinden von USB-Sticks nicht nutzen kann? Außerdem: wenn die File-Permissions "Easy" statt "Secure" sind, dann sind doch nicht Tür und Tor des Systems offen. Und ohne, dass man etwas darf, hat man auch wenig Lust, etwas auszuprobieren und wird so auch nichts dazulernen. Dann wäre Linux heute nicht das, was es ist. Man sollte lernwillige Benutzer nicht durch zu hohe Hürden vergraulen und niemandem vorschreiben, dass er gefälligst mit höchster Sicherheit anfangen und sie erst herunterschrauben soll, wenn er was Vernünftiges mit dem System anfangen will. Umgekehrt wäre es richtig. Dann kann jeder seine Sicherheit ganz individuell hochschrauben (lassen). Freilich sollte das System dem Benutzer bei der Installation die Einstellung einer Mindestsicherheit empfehlen und erklären.
Aber, die Entwickler könnten ein bißchen von Windows Firewalls abgucken und Abfragen einbauen. Will ein Programm raustelefonieren, sollte eine Abfrage erscheinen.
Meiner Erfahrung nach nützt das überhaupt nichts, weil unbedarfte Benutzer dann immer auf "JA" klicken, wenn sie andernfalls nicht mehr vernünftig weitermachen könnten (wird schon schiefgehen). Bei manchen Aktionen unter Windows, wie dem Installieren neuer Software, wird man nach dem Administrator-Passwort gefragt. Ist der Benutzer auch der Eigentümer des Rechners, dann möchte ich den sehen, der es dann nicht eingibt. Aber nur einem winzigen Bruchteil davon wird bewusst sein, dass dann der Installer sehr viel, wenn nicht alles darf. Wenn jemand sein eigenes System vor der eigenen Ahnungslosigkeit schützen möchte, sollte er/sie jemand anderen für die Administration bezahlen, und nur diesem das Root-Passwort geben. Aber hat er deshalb die totale Sicherheit? Nein, denn hier geht man das Risiko eines Vertrauensbruchs ein, dessen Wahrscheinlichkeit auch nicht Null ist. Also plädiere ich für ein Mindestmaß anstatt für ein Höchstmaß an Sicherheit bei einem frisch installierten System. Außerdem muss die Distri schon bei der Installation deutlich auf die Möglichkeiten der Sicherheitseinstellungen hinweisen und mehr die Bedeutung der einzelnen Stellschrauben erklären, als das openSUSE aktuell tut. Bei einem Router sehe ich die Sache anders, wie ich schon schrieb. Besten Gruß Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 08.11.2014 um 17:28 schrieb Thomas Michalka:
Wenn Du als Mieter vor Deine Haustür gehst, kann Dich ein Dachziegel treffen. Wenn das nicht passiert, hast Du Glück gehabt, weil sich trotz mangelnder Sorgfalt Deines Vermieters trotzdem gerade kein Ziegel gelöst hat. Wenn Du dann an der Gehsteigkante stehst, kann Dich ein Außenspiegel eines Omnibus umnieten, wenn das nicht passiert, kannst Du beim Versuch, die Straße zu überqueren, von einem Auto erfasst und totgefahren werden. Willst Du angesichts dieser Risiken (AKA relative Unsicherheit) Deine Wohnung oder Dein Haus denn nicht mehr verlassen? Wenn Du von zu Hause weggehst, läßt Du dann die Hauseingangstür offen?
Wollen wir also wirklich totale Sicherheit in den Netzen, sogar innerhalb unseres eigenen LAN? Ich jedenfalls nicht, weil mich dann mein LAN und meine Rechnersysteme mehr behindern als mir nützen würden. In meinem "internen" Netzwerk gibt es "Microsoft" und Linux Rechner. Mit einem Windows Rechner ist die Wahrscheinlichkeit groß, das man sich irgendein digitales Ungeziefer einfängt (in meinem Fall ist die Wahrscheinlichkeit klein, da ich mich nicht in den dunklen Ecken aufhalte, trotzdem die Gefahr ist omnipräsent).
Aber muss man deshalb nach der Systeminstallation gleich alle einschaltet haben? Vor etlichen Jahren, Mittlere Zeiten von XP. Ich hatte eine XP CD ohne Service Pakete. Hatte XP neu installiert mit Internet, es hatte gar nicht lange gedauert, wahr ich infiziert, ohne das ich überhaupt den Browser gestartet hätte. Hatte damals noch keinen Router. Du drehst mein Argument gegen mich um:
War und ist nicht meine Absicht, will bloß den Banditen und manchen Geheimdiensten das Leben schwer wie möglich machen.
Was nützt einem ein nahezu völlig sicherer Rechner, wenn man elementare Dinge, wie das Einbinden von USB-Sticks nicht nutzen kann? Gerade das meine ich, z.B. wenn man ein Gerät anstöpselt, soll eine Sicherheitsabfrage erscheinen und wenn Geräte angestöpselt werden auch ein Passwortabfrage. Außerdem muss die Distri schon bei der Installation deutlich auf die Möglichkeiten der Sicherheitseinstellungen hinweisen und mehr die Bedeutung der einzelnen Stellschrauben erklären, als das openSUSE aktuell tut. Hand aufs Herz, Du ließt auch nicht das ganze oder jedes Kleingedruckte? Bei einem Router sehe ich die Sache anders, wie ich schon schrieb. Hatte ich auch zur Kenntnis genommen. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 08.11.2014 um 19:03 schrieb Hugo Egon Maurer:
Am 08.11.2014 um 17:28 schrieb Thomas Michalka:
Wenn Du als Mieter vor Deine Haustür gehst, kann Dich ein Dachziegel treffen. Wenn das nicht passiert, hast Du Glück gehabt, weil sich trotz mangelnder Sorgfalt Deines Vermieters trotzdem gerade kein Ziegel gelöst hat. Wenn Du dann an der Gehsteigkante stehst, kann Dich ein Außenspiegel eines Omnibus umnieten, wenn das nicht passiert, kannst Du beim Versuch, die Straße zu überqueren, von einem Auto erfasst und totgefahren werden. Willst Du angesichts dieser Risiken (AKA relative Unsicherheit) Deine Wohnung oder Dein Haus denn nicht mehr verlassen?
Wenn Du von zu Hause weggehst, läßt Du dann die Hauseingangstür offen?
Mir ist jetzt nicht ganz klar was Du meinst, denn was hat meine Haustür mit den Risiken außerhalb des Hauses zu tun (abgesehen vom Risiko des unbefugten Eindringens)? Aber natürlich lasse ich sie nicht offen, denn das wäre fahrlässig. Aber unabhängig von der Haustür bin ich mir der Risiken bewusst, die draußen auf mich warten. Dennoch blicke ich mich nicht ständig ängstlich um, und überlege nicht dauernd, welches Ungemach mir als nächstes drohen könnte. In Analogie zur Hauseingangstür: ich öffne keine Ports in der FW für den Zugriff aus dem Internet, die ich nicht selber unbedingt brauche. Sicher drohen dann mehr Risiken als ganz ohne offene Ports.
Wollen wir also wirklich totale Sicherheit in den Netzen, sogar innerhalb unseres eigenen LAN? Ich jedenfalls nicht, weil mich dann mein LAN und meine Rechnersysteme mehr behindern als mir nützen würden.
In meinem "internen" Netzwerk gibt es "Microsoft" und Linux Rechner. Mit einem Windows Rechner ist die Wahrscheinlichkeit groß, das man sich irgendein digitales Ungeziefer einfängt (in meinem Fall ist die Wahrscheinlichkeit klein, da ich mich nicht in den dunklen Ecken aufhalte, trotzdem die Gefahr ist omnipräsent).
Wie wäre es, wenn Du Deine MS-Rechner von den anderen mittels VLAN abschottest? Vielleicht brauchst Du ja keinen Zugriff von diesen bzw. auf diese aus Deinem übrigen LAN. Die MS-Rechner könnten dann aus ihrem VLAN heraus genauso ins Internet, wie Deine anderen Rechner -- nur untereinander geht dann nix. Wie sicherst Du (bitte keine genauen Angaben, mache hier ja kein Social Engineering) denn Deine anderen Rechner gegen mögliche Zugriffe von den MS-Rechnern aus?
[...]
Vor etlichen Jahren, Mittlere Zeiten von XP. Ich hatte eine XP CD ohne Service Pakete. Hatte XP neu installiert mit Internet, es hatte gar nicht lange gedauert, wahr ich infiziert, ohne das ich überhaupt den Browser gestartet hätte. Hatte damals noch keinen Router.
Die FW auf dem Router hätte wahrscheinlich auch nur Pakete ausgefiltert aber keine Malware, die über Protokolle der Anwendungsebene hereinkommt bzw. Schwächen in des nicht häufig gepatchten OS und der Anwendungen.
Du drehst mein Argument gegen mich um:
War und ist nicht meine Absicht, will bloß den Banditen und manchen Geheimdiensten das Leben schwer wie möglich machen.
Ist ja legitim und vernünftig, aber das hat zunächst eher wenig mit den File-Permissions auf einzelnen Rechnern im LAN zu tun, sondern mehr mit der stufenweisen Absicherung von der Außenseite her (FW, evtl. mit einem Paketfilter innen und einem außen, dazwischen einem Dual Homed Bastion Host in der DMZ, der in beiden Richtungen gar keine Pakete mehr durchleitet, sondern für jedes Anwendungsprotokoll einen Proxy gibt).
Was nützt einem ein nahezu völlig sicherer Rechner, wenn man elementare Dinge, wie das Einbinden von USB-Sticks nicht nutzen kann?
Gerade das meine ich, z.B. wenn man ein Gerät anstöpselt, soll eine Sicherheitsabfrage erscheinen und wenn Geräte angestöpselt werden auch ein Passwortabfrage.
Ich muss es mal überprüfen, aber ich glaube, dass auch bei File-Permissions = "Easy" eine Einbinden eines Sticks nicht geht, wenn gerade der Bildschirm gesperrt ist, bin aber nicht sicher. Falls es nicht geht, hat man auch für ein automatisches Einbinden ja vorher schon das Benutzerpasswort am Lock-Screen eingegeben. Freilich ist es möglich, dass man den Bildschirm entsperrt hat, nochmal kurz weggeht und während der Abwesenheit eine Unbefugter seinen Stick einstöpselt. Aber dann hat halt der menschliche Faktor zugeschlagen :-( Klar man kann für das Einbinden eines externen Dateisystems nochmal das Passwort des Benutzers verlangen, wenn der Bildschirm nicht gesperrt ist. Aber in dem Fall darf der böse Bube inzwischen sowieso schon alles, was Du selber auch darfst -- nur keinen Stick mounten, was ein geringfügiger Nachteil ist, den man vielleicht sogar mit einer eigenen Regel beseitigen kann (kommt wohl auf die Rangfolge bei der Regelabarbeitung an).
Außerdem muss die Distri schon bei der Installation deutlich auf die Möglichkeiten der Sicherheitseinstellungen hinweisen und mehr die Bedeutung der einzelnen Stellschrauben erklären, als das openSUSE aktuell tut.
Hand aufs Herz, Du ließt auch nicht das ganze oder jedes Kleingedruckte?
Es soll ja nicht klein gedruckt sein, sondern riesengroß! Dafür plädiere ich! Obwohl es derzeit bei oS (und auch bei anderen Distris?) nicht so ist, lese ich genauestens die Erklärungen bei den Sicherheitseinstellungen in YaST, aber die erscheinen mir aktuell doch als sehr dürftig, und ich lese noch einiges mehr in der einschlägigen Literatur, u.a. zur Netzwerksicherheit. Besten Gruß Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
Hendrik Woltersdorf -
Hugo Egon Maurer -
Jürgen Heiler -
Thomas Michalka -
Wolfgang Rosenauer