[linux-l] Passwort bei rsync

Volker Grabsch vog at notjusthosting.com
So Okt 2 19:49:10 CEST 2011


Hallo Marek,

(kurzer Hinweis: Irgendwie sind deine Umlaute hier nicht
 angekommen. Daher die Fragezeichen im zitierten Text.)


Marek Froehlich schrieb:
> On Sat, Oct 01, 2011 at 08:18:53PM +0200, Volker Grabsch wrote:
> > 
> > Welchen Zweck hat der separate rbackup-Account? Da er via
> > sudo beliebige Rsync-Kommandos als root ausführen kann, hat
> > er im Endeffekt Root-Rechte, bzw. kann sie sich jederzeit
> > auf 100 einfachen Wegen beschaffen.
> > 
> > Somit gaukelt es eine Sicherheit vor, die gar nicht vorhanden
> > ist, sowas finde ich gefährlich.
> 
> Sehr guter Einwand! Allerdings lag meiner L?sung der Ansatz
> zu Grunde, UNTER KEINEN UMST?NDEN remote-root-logins zu gestatten:
> Root auf Server A soll nicht automatisch root auf Server B werden
> k?nnen.

Meine Kritik ist, dass du aber genau das tust, indem du
einem normalen User so viele Rechte gibst, dass er praktisch
einen Root-Zugang hat.

Genau das ist meiner Ansicht nach auch die Schattenseite
von Sudo - es verleitet zu genau solchen Konstruktionen
und vermittelt dabei zudem ein falsches Sicherheitsgefühl.

> Der aufgezeigte Weg ?ber sudo auf B hat Sicherheitsschw?chen -
> keine Frage:
> - ich kann mit rsync beliebige Dateien auf B ueberschreiben,
>   z. B. /etc/sudoers ...
> - mglw. gelingen mir shell-escapes mit rsync auf B
> - ... (Vorschl?ge?)  

Du kannst die Shell auf SUID-Root setzen, du kannst
in /etc/shadow das Root-Passwort ändern, du kannst
ein beliebiges Script als Root-Cronjob eintragen,
du kannst dir einen zweiten Account mit Root-Rechten
anlegen, und so weiter.

Das nur als "Schwäche" oder Sicherheitslücke zu
bezeichnen wäre genauso, als würdest du ein paar
herumliegende Steine als "Mauer mit großen Löchern"
bezeichnen. [an diese Stelle bitte eine passende
Analogie zur Antiviren-Industrie einfügen]

Wenn du jemandem Sudo-Zugriff auf Rsync gibst, kannst
du ihm auch gleich das Root-Passwort geben. :-)

> Ich werde mir in den n?chsten Tagen mal die man-pages im
> Detail vornehmen und ein bisschen testen. Wir k?nnen ja
> Verbesserungsvorschl?ge sammeln und Volker "spielt" den
> boesen root-admin auf A, der schlimme Dinge auf B mit rsync
> anstellen will ;-)

> Ein alternativer Ansatz w?re ein rsync-Daemon auf B laufen
> zu lassen - pruefe ich auch mal.

Das ist eine Möglichkeit, da musst du dann aber schauen,
ob du weiterhin eine verschlüsselte Datenübertragung, Login
per PublicKey, etc hast. Diese Dinge kriegst du ja bei SSH
von Hause aus mit.

Mein Vorschlag wäre, die Sudo-Zeile weiter zu verschärfen,
sodass Rsync nur mit ganz bestimmten Parametern aufgerufen
werden kann. Soweit ich mit erinnere geht das aber nicht so
leicht. Sudo ist hier nicht wasserdicht: Du kannst zwar die
ersten Parameter festlegen, aber Sudo erlaubt dann immer noch
das Hinzufügen weiterer Parameter. So hat es der Angreifer
zwar schwerer, könnte dich aber durch geschickte Zusatzparameter
vielleicht doch noch austricksen.

Mein zweiter Vorschlag wäre daher, ein (Shell-)Script zu
schreiben, das RSync genau mit den benötigten Parameter
aufruft, und sonst nichts weiter tut. Insbesondere keine
Parameter weiterleitet oder so. Dieses Shell-Script kannst
du dann via Sudo erlauben. Das sollte dann wasserdicht sein.

Als dritten Vorschlag hätte ich, dass du Sudo ganz heraus
wirfst, und stattdessen ein kleines C-Programm (3-Zeiler)
schreibst, das Rsync mit diesen Parametern aufruft. Diesem
Programm kannst du dann das SUID-Bit verpassen, und die
Ausführung nur dem rbackup-User erlauben:

    chown root:rbackup dein-binary
    chmod 4750         dein-binary

Es muss kein C-Programm sein, aber irgendwas, was du zu
einem Binary compilieren kannst. Denn bei Shell- oder
Perl-Scripten (alles was nur ne #!-Zeile hat) ist das
SUID-Bit wirkungslos.

Dieses Ding könntest du theoretisch sogar dem User rbackup
als Shell setzen. :-)

Allerdings bleibt das grundsätzliche Problem, dass der
Benutze rbackup stets vollen Lesezugriff auf das gesamte
System hat - alle Datenbanken, alle Passwort-Hashes und
so weiter. Klar, muss er ja auch, sonst wäre das Backup
wohl kaum möglich.

Worauf ich hinaus will: Wahrscheinlich hast du eh verloren,
wenn irgendjemand diesen Account kapert. Der Angreifer
kann dann zwar keine Spams über deinen Server versenden,
kommt aber an alle sensiblen Daten heran.

Die Alternative wäre, dass dein System per Cronjob ein
großes Backup-Tar(GZ) baut, und dieses per GPG verschlüsselt.
Dann saugt sich dann der Backup-Server (oder du schiebst
es auf den Backup-Server hoch). Das hat den Vorteil, dass
erstmal niemand etwas mit dem Backup anfangen kann, weder
das System selbst, noch der Backup-Server.

Aber es hat den großen Nachteil, dass das Backup in keiner
Weise mehr effizient abläuft, denn RSync hat hier keine
Chance mehr, irgendwas zu optimieren. (Trotzdem würde ich
weiterhin RSync statt SCP nehmen, weil bei Netzwerkproblemen
RSync dein halb-übertragenes Backup fortsetzen kann, während
SCP den Download wieder von vorn beginnen müsste.)


Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---



Mehr Informationen über die Mailingliste linux-l