Capabilities und Dateisystemzugriffe

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Capabilities und Dateisystemzugriffe

Beitrag von scientific » 14.05.2017 19:50:10

Hi Leute.

Btrfs kann man ja nur als root sinnvoll bearbeiten. Sprich snapshots machen, btrfs send und receive usw.

Wenn ich jetzt per ssh einen Snapshot auf einen entfernten rechner sichern möchte, muss ich mich dort als root per ssh einloggen...

Jetzt kann man natürlich ausschließlich nur per key den Login erlauben, aber schön ist das nicht.

Würde das auch mit Capabilities als anderer User funktionieren? Oder bringt das - so es ginge - überhaupt etwas, da dieser andere User erst recht wieder am gesamten Dateisystem fummeln dürfte...?

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Capabilities und Dateisystemzugriffe

Beitrag von breakthewall » 15.05.2017 05:20:45

Warum ist das nicht schön? Du kannst Dich ebenso auch via Public-Key-Verfahren als Nutzer dort anmelden, und Dich dann bei Bedarf via su oder sudo entsprechend zu Root hochstufen, sofern das Passwort bekannt ist. Von daher besteht keine Pflicht sich direkt als Root einloggen zu müssen wenn man das nicht will, womit man auch das Login via Public-Key-Verfahren nicht torpediert. Und damit das mit normalen Nutzern funktioniert, benötigen sie natürlich die genutzten Schlüssel im jeweiligen Home-Verzeichnis, dann verbindest Dich von Nutzer zu Nutzer, gibst Dir eben anschließend erst Rootrechte und erstellst dann die Snapshots. Hinzu kommt, dass jeweiligen Nutzern keine erweiterten Rechte geben musst, was bekanntlich keine gute Idee ist. Zumindest denke Ich mal, dass Ich Dich da richtig verstanden habe.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Capabilities und Dateisystemzugriffe

Beitrag von MSfree » 15.05.2017 08:39:14

scientific hat geschrieben:Wenn ich jetzt per ssh einen Snapshot auf einen entfernten rechner sichern möchte, muss ich mich dort als root per ssh einloggen...
Jein, du brauchst dich nicht als root einzuloggen. Es reicht, wenn du einen neuen User mit der User-ID Null anlegst und dich unter dem Usernamen einlogst.

Den SSH-Server kannst du dann so konfigurieren, daß er z.B. Logins von eine bestimmten IP-Adresse für den neuen User ohne Keyfile zuläßt.

Andererseits könntest du dem neuen User auch ein von root unterschiedliches Keyfile anlegen. Dein Snapshot wird wohl automatisiert ablaufen und das SSH-Login per Script durchgeführt. Es ist doch kein Problem, dem Script das Keyfile in die Kommandozeile des SSH-Aufrufes einzutragen.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Capabilities und Dateisystemzugriffe

Beitrag von scientific » 15.05.2017 10:04:10

Genau. Das Backup soll automatisch per Skript laufen. Da ist nix mit Rechteeskalation per sudo.

Bestimmte IP freigeben wird nicht klappen, da dynamische IP im Spiel sind. Allerdings hab ich einen dyn-DNS-Dienst im Einsatz.

Ich hab ein Beispiel gefunden, und der Author sieht den Login als root nur mit ungeschütztem Keyfile ebenso problematisch und hat auf der serverseite ein Shellskript dazwischengeschaltet. Nur hab ich noch nicht begriffen, wie das funktioniert. Dieses Skript erlaubt bei bestimmten Logins nur ausgewählte Befehle.

Eventuell ist ja wirklich eine Lösung, wo ein nichtpriviligierter User einen (Differenz)-Sanpshot auf die Platte des Servers schreibt, und dieser bindet dann in einem eigenen Prozess den Snapshot ins Dateisystem ein, der sicherere Weg. Für die Abfragen des Dateisystems kann ich dann gezielt dem unprivilegierten User per sudo klar definierte Befehle erlauben.

Dieser Weg erfordert aber ungleich mehr Platz auf der Festplatte und doppelte IO-Last.

Oder ich schreib einen Service, der von einem unpriviligierten User den Snapshot entgegennimmt und als su einbindet... Aber ob das so viel besser ist?
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: Capabilities und Dateisystemzugriffe

Beitrag von TomL » 15.05.2017 11:30:12

Ich verstehe im Moment auch nicht so recht, wo überhaupt das Problem ist. Ich würde einen neuen User einrichten, der keine reale Person ist, ein pwd vergeben und die pubkeys bei dem ins Verzeichnis legen und gut ist. Solange sich keiner root-rechte aneignen kann, kann das ja auch keiner nutzen. Man kann sich mit dem user per ssh anmelden, mit su zu root werden und den snapshot starten. Was ist daran bedenklich?

Und wenn das zu unsicher ist, würde ich einfach via unit einen Dienst starten, der auf einem definierten Port auf ein bestimmtes Codewort wartet. Das ist relativ simple via bash zu lösen. Kommt das Codewort macht er seinen snapshot und wartet danach auf das nächste eintreffen des Codeworts. Und weil der dienst als root läuft, gibts da auch keine Rechte-Probleme. Vermutlich ist das schlimmste, was passieren kann, dass jemand mit Port und Codewort nen neuen snapshot-lauf auslöst.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Capabilities und Dateisystemzugriffe

Beitrag von MSfree » 15.05.2017 11:34:55

TomL hat geschrieben:Vermutlich ist das schlimmste, was passieren kann, dass jemand mit Port und Codewort nen neuen snapshot-lauf auslöst.
Nunja, wenn man 1000 mal pro Sekunde ein Snapshot auslöst, kann man damit potentiell Client und Server DOSen.

TomL

Re: Capabilities und Dateisystemzugriffe

Beitrag von TomL » 15.05.2017 11:36:46

Nur wenn man das schlampig implementiert. Ich nutze das an anderer stelle und da ist so etwas nicht möglich

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Capabilities und Dateisystemzugriffe

Beitrag von scientific » 15.05.2017 11:49:31

Nun, wie schon erläutert, das passiert nicht manuell sondern im Skript.

Code: Alles auswählen

btrfs send <snapshot> |ssh root@backupserver.example btrfs receive </path/to/pool>
wäre der aufruf im Skript.
Das Problem dabei ist, wenn ich die Variante mit zwischenspeichern wähle, dass die Reihenfolge der Snapshots passen muss, die dann von einem eigenen Service mit root-rechten eingespielt werden. Durch eine rekursive Subvolume-Struktur müssen nämlich die Platzhalter-Directories vorher gelöscht werden (sind leer) und dann an genau dieser Stelle das Subvolume eingespielt werden.

Andere Aufrufe wären

Code: Alles auswählen

ssh root@backupserver.example btrfs subvol list -o </path/to/pool>
Auch das muss root ausführen... Hier könnte ich mich mit sudo behelfen.

Da ist nix mit einloggen und dann mittels sudo zu root werden. Ich muss direkt als root auf die Maschine per ssh.

Abgesehen davon ist es dem Rechner ziemlich egal, ob der Account einer realen Person gehört oder nicht... Wer die Logindaten hat, kommt rein.

Und einen ssh-Key ohne Passwort für den Root-Zugriff... da hab ich einfach Bauchweh. Aber

Die Frage ist halt, wo man sich ein größeres Loch aufreißt. Login von root mit ssh-Key erlauben oder per sudo nur bestimmte Befehle erlauben, ansonsten ein unpriviligierter User...

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: Capabilities und Dateisystemzugriffe

Beitrag von TomL » 15.05.2017 19:30:17

scientific hat geschrieben:Ich muss direkt als root auf die Maschine per ssh.
Nö, "müssen" musst Du das nicht.... es gibt eben auch Alternativen, um einen "entfernten" Job mit root-Rechten zu starten... ohne dass man den root-ssh-login öffnen oder einen User berechtigen muss ... und scheinbar -wie Du selber sagst- bereitet Dir beides Bauchschmerzen.
scientific hat geschrieben:Die Frage ist halt, wo man sich ein größeres Loch aufreißt. Login von root mit ssh-Key erlauben oder per sudo nur bestimmte Befehle erlauben, ansonsten ein unpriviligierter User...
Starte den Job doch einfach bei Systemstart und lass ihn dann darauf warten, dass jemand sagt "jetzt los". Er hat dann -wenn er losrennt- automatisch root-Rechte und Du kannst Du ihn vorher einfach nach dem dem ssh-login eines völlig unberechtigten User informieren, dass er losrennen soll. Das ist dann kein Job starten, sondern nur den bereits gestarteten Job informieren, dass er jetzt seine Arbeit machen soll. Man kann es sogar so einrichten, dass jeder unberechtigter User "jetzt los" sagen kann, und zwar ohne am Rechte-System oder mit der sudoers oder mit dem Polkit rumzuschrauben. Statt "jetzt los" kannst du aber auch "hühott" oder "rapido" oder sonst was sagen... *fg*.... Ihr zwei (Du und der Job) müsst euch nur aufs gleiche einigen.....

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Capabilities und Dateisystemzugriffe

Beitrag von scientific » 16.05.2017 14:30:32

Nun... Schön wärs, wenn man einem unprivilegierten User mittels CAPS Sonderrechte einräumen könnte...
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: Capabilities und Dateisystemzugriffe

Beitrag von TomL » 16.05.2017 17:16:55

scientific hat geschrieben:Nun... Schön wärs, wenn man einem unprivilegierten User mittels CAPS Sonderrechte einräumen könnte...
Beunruhigt Dich dabei nicht ein wenig, dass über das dritte Berechtigungssystem möglicherweise die Gefahr unkalkulierbarer Wechselwirkungen zu sudo, Gruppe sudo, sudoers und dem Polkit bestehen könnten? Ich hätte da das Gefühl von kompletten Kontrollverlust (ohne das sachlich erklären zu können), weil ich 3 gleichzeitig aktive Rechtesysteme vermutlich nicht im Auge behalten könnte. Deswegen gibts bei mir auch wirklich nur "König" root, der alles darf und für User explizite Berechtigungen übers Polkit. Wenn ich dabei mal wieder an "wanna cry" denke, dann fühle ich mich zu meiner Prämisse bestätigt "so einfach wie möglich, so kompliziert wie nötig.... bestmögliche Wirkung bei geringstmöglichem Risikopotential.... nicht mehr als das, was für die Aufgabe mindestens zwingend notwendig ist.". Damit würden die CAPS bei mir rausfallen....

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Capabilities und Dateisystemzugriffe

Beitrag von scientific » 16.05.2017 17:59:09

So wie ich caps verstanden habe, würde ich damit auf sudo, su und root-anmeldung verzichten können.
Su und sudo erzeugen über pam eine ganze session. Da tun sich doch potentielle lücken auf.
Mit caps kann ich sogar auf das setuid-bit und den daraus resultierenden risiken verzichten. Deshalb habens bei fedora durch caps bei allen anwendungen das setuid-bit rausgenommen.

Das gefällt mir vom prinzip gut. Nur muss ich erst lernen, wie es funktioniert, und obs für meine Anwendung geeignet ist.

Deshalb meine Frage.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Capabilities und Dateisystemzugriffe

Beitrag von scientific » 16.05.2017 19:55:19

http://www.linux-magazin.de/Ausgaben/20 ... fuer-Pcaps

Ein interessanter Artikel zum Thema
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Capabilities und Dateisystemzugriffe

Beitrag von scientific » 17.05.2017 14:53:04

Noch eine interessante Geschichte dazu:

https://www.slideshare.net/mobile/Hazel ... ync-setcap
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten