einem root-Prozess Schreibzugriffe nur in einem Directory erlauben

[Stefan Klein]

Am Do., 18. Okt. 2018 um 16:13 Uhr schrieb Marc Haber <

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.

Vielleicht hilft dir rssh weiter, eine restricted shell mit der man
Benutzer auf rsync, sftp, scp usw. einschrÀnken kann.
Ich bin nicht sicher ob man die auch mit "command" in der authorized_keys
nutzen kann.
100% passen wird rssh wohl nicht, aber evtl. bekommst du sie passend
gemacht.
Ist als debian paket verfÌgbar allerdings schon etwas lÀnger frisch.


GrÌße,
Stefan

[d***@ts.fujitsu.com]

Rsync -vRae ssh /dir server:/

Von meinem iPhone gesendet

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).
- 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

[d***@ts.fujitsu.com]

P.s. Und das ist für den normal Gebrauch hinreichend sicher

Von meinem iPhone gesendet

Post by d***@ts.fujitsu.com
Rsync -vRae ssh /dir server:/
Von meinem iPhone gesendet

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).
- 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.

[Alexander Dahl]

Hallo Marc,

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.

Ich kann mich dunkel erinnern, dass ich damit auch schon erheblichen
Stress hatte.

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.

Bin nicht ganz sicher, aber hilft Dir rrsync weiter? Das ist ein
Skript, das mit rsync mitkommt, im Debian-Paket hier:

/usr/share/doc/rsync/scripts/rrsync.gz

Muss man halt auspacken und irgendwo hin tun, damit es benutzen kann.

Grüße
Alex

[Peter Wiersig]

- selinux (ich möchte nicht das ganze System umstricken müssen)
Any ideas?

AppArmor sollte dafuer deutlich schlanker sein. So zumindest, was mir
beim Einlesen dazu im Kopf blieb.

Peter

[Uwe Kleine-König]

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).
- 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?

https://lwn.net/Articles/767547/ klingt als wÀre es, was Du brauchst.

Leider noch nicht fertig :-|

Liebe GrÌße
Uwe