Re: einem root-Prozess Schreibzugriffe nur in einem Directory erlauben
P.s. Und das ist für den normal Gebrauch hinreichend sicher
Von meinem iPhone gesendet
> Am 18.10.2018 um 18:05 schrieb "dirk.laurenz@ts.fujitsu.com" <dirk.laurenz@ts.fujitsu.com>:
>
> Rsync -vRae ssh /dir server:/
>
> Von meinem iPhone gesendet
>
>> Am 18.10.2018 um 16:13 schrieb Marc Haber <mh+debian-user-german@zugschlus.de>:
>>
>> Hallo,
>>
>> die Situation: Zwei Directories (die wie der Inhalt root gehören
>> müssen)auf zwei Rechnern sollen synchron gehalten werden. Hierfür ist
>> ein rsync-Mechanismus etabliert. Sicherheit wird dadurch hergestellt,
>> dass der von rsync verwendete Key im /root/.ssh/authorized_keys auf
>> command="rsync ..." mit den vom client gewählten Optionen festgenagelt
>> ist.
>>
>> Diese Optionen ändern sich von Zeit zu Zeit, was jedes Mal zu
>> schwierig zu debuggenden Fehlern führt, bis man die authorized_keys
>> files nachgezogen hat. Das nervt.
>>
>> Deswegen hatte ich die Idee, den rsync-Prozess auf der Serverseite mit
>> generischen Argumenten zu starten, ihn aber z.B. mit einem Wrapper so
>> einzuschränken, dass er nur im gewollten Ziel schreiben darf ("schreib
>> außerhalb Deines Bereiches und Du stirbst"). Interessanterweise
>> scheint das noch niemand gemacht zu haben, jedenfalls noch nicht so
>> weit, dass man das Ergebnis hätte paketieren können.
>>
>> Am liebsten würde ich etwas wie command="restrict-wrapper
>> --write-dir=/etc/dhcp/synced $SSH_ORIGINAL_COMMAND" schreiben können
>> (abgesehen davon, dass $SSH_ORIGINAL_COMMAND in der authorized_keys
>> selbst nicht zur Verfügung steht).
>>
>> Was ich nicht will, ist:
>> - selinux (ich möchte nicht das ganze System umstricken müssen)
>> - mount namespaces / bind-mounts
>> - eine systemd-unit (passt hier nicht und benutzt auch nur mount
>> namespaces und bind-mounts)
>> - chroot (das braucht das rsync-Binary plus Libraries innerhalb des
>> Zielverzeichnisses, was Update-Issues bringt.
>>
>> Habt ihr da geniale Ideen?
>>
>> Und ja, sobald ich etwas als root aufrufe, muss ich ihm ein gewisses
>> Vertrauen entgegenbringen. Bei rsync ist das vorhanden, bei
>> demjenigen, der rsync auf der Gegenseite aufruft, eher nicht. Ich
>> möchte mich also nicht gegen Schwachstellen im auf dem Server
>> installierten rsync, sondern gegen einen böswilligen Aufrufer
>> absichern.
>>
>> Any ideas?
>>
>> Grüße
>> Marc
>>
>> --
>> -------------------------------------- !! No courtesy copies, please !! -----
>> Marc Haber | " Questions are the | Mailadresse im Header
>> Mannheim, Germany | Beginning of Wisdom " |
>> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
>>
Reply to: