| Message ID | 20200107110320.17359-1-fff@chrisi01.de |
|---|---|
| State | Superseded |
| Headers | show |
diff --git a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd index d53eb43..28384b9 100644 --- a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd +++ b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd @@ -15,9 +15,18 @@ uci batch <<EOF set fastd.fff.mtu='1426' set fastd.fff.on_up="/etc/fastd/fff/up.sh" set fastd.fff.secure_handshakes='0' - set fastd.fff.secret="generate" EOF +if ! secret=$(uci -q get fff.fastd.secret); then + secret=$(/usr/bin/fastd --generate-key --machine-readable) + uci set fff.fastd='fff' + uci set fff.fastd.secret="$secret" + uci commit fff +fi +uci set fastd.fff.secret="$secret" +uci commit fastd + + [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff ln -s /tmp/fastd_fff_peers /etc/fastd/fff/peers echo "#!/bin/sh" > /etc/fastd/fff/up.sh
Also ich bin den Patch auch gerade nochmal mit Christian durchgegangen und das sieht IMHO sauber aus. Reviewed-by: lemmi <lemmi@nerd2nerd.org> On 07.01.20 12:03, Christian Dresel wrote: > To use a whitelist easy, it is neccessary to make the fastd key updatesafe > This patch safe the key to uci fff and recover it, if a key is after the update available > > --- > Changes in v2: > - use variable in if > - remove trailing whitespace > - remove -q > --- > Changes in v3: > - use only one variable $secret > --- > > Signed-off-by: Christian Dresel <fff@chrisi01.de> > --- > .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > index d53eb43..28384b9 100644 > --- a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > +++ b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > @@ -15,9 +15,18 @@ uci batch <<EOF > set fastd.fff.mtu='1426' > set fastd.fff.on_up="/etc/fastd/fff/up.sh" > set fastd.fff.secure_handshakes='0' > - set fastd.fff.secret="generate" > EOF > > +if ! secret=$(uci -q get fff.fastd.secret); then > + secret=$(/usr/bin/fastd --generate-key --machine-readable) > + uci set fff.fastd='fff' > + uci set fff.fastd.secret="$secret" > + uci commit fff > +fi > +uci set fastd.fff.secret="$secret" > +uci commit fastd > + > + > [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff > ln -s /tmp/fastd_fff_peers /etc/fastd/fff/peers > echo "#!/bin/sh" > /etc/fastd/fff/up.sh
Hallo Christian, siehe unten. > -----Original Message----- > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of > Christian Dresel > Sent: Dienstag, 7. Januar 2020 12:03 > To: franken-dev@freifunk.net > Subject: [PATCH v3] fastd: make secret key updatesafe > > To use a whitelist easy, it is neccessary to make the fastd key updatesafe > This patch safe the key to uci fff and recover it, if a key is after the update > available > > --- > Changes in v2: > - use variable in if > - remove trailing whitespace > - remove -q > --- > Changes in v3: > - use only one variable $secret > --- > > Signed-off-by: Christian Dresel <fff@chrisi01.de> > --- > .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > index d53eb43..28384b9 100644 > --- a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > +++ b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > @@ -15,9 +15,18 @@ uci batch <<EOF > set fastd.fff.mtu='1426' > set fastd.fff.on_up="/etc/fastd/fff/up.sh" > set fastd.fff.secure_handshakes='0' > - set fastd.fff.secret="generate" > EOF > > +if ! secret=$(uci -q get fff.fastd.secret); then > + secret=$(/usr/bin/fastd --generate-key --machine-readable) uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel früher generiert als bisher (denn die Settings werden erst ausgewertet, wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, ob man bei dieser Variante nicht irgendwann dieselben Keys für verschiedene Router generiert. Für den Aufruf an sich sollte die Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. > + uci set fff.fastd='fff' > + uci set fff.fastd.secret="$secret" > + uci commit fff Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem frischen System). Daher wird das auf einem frischen System zu einem Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von 98-configure-fff nach vorne verlegen (was aber wieder diverse Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du ersteres machst. > +fi > +uci set fastd.fff.secret="$secret" > +uci commit fastd > + > + Eine newline reicht mE. Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal diskutieren, testen wird man das schlecht können. Grüße Adrian > [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff > ln -s /tmp/fastd_fff_peers /etc/fastd/fff/peers > echo "#!/bin/sh" > /etc/fastd/fff/up.sh > -- > 2.11.0
Hi Adrian On 07.01.20 15:07, Adrian Schmutzler wrote: > Hallo Christian, > > siehe unten. > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of >> Christian Dresel >> Sent: Dienstag, 7. Januar 2020 12:03 >> To: franken-dev@freifunk.net >> Subject: [PATCH v3] fastd: make secret key updatesafe >> >> To use a whitelist easy, it is neccessary to make the fastd key updatesafe >> This patch safe the key to uci fff and recover it, if a key is after the update >> available >> >> --- >> Changes in v2: >> - use variable in if >> - remove trailing whitespace >> - remove -q >> --- >> Changes in v3: >> - use only one variable $secret >> --- >> >> Signed-off-by: Christian Dresel <fff@chrisi01.de> >> --- >> .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 ++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> index d53eb43..28384b9 100644 >> --- a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> +++ b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> @@ -15,9 +15,18 @@ uci batch <<EOF >> set fastd.fff.mtu='1426' >> set fastd.fff.on_up="/etc/fastd/fff/up.sh" >> set fastd.fff.secure_handshakes='0' >> - set fastd.fff.secret="generate" >> EOF >> >> +if ! secret=$(uci -q get fff.fastd.secret); then >> + secret=$(/usr/bin/fastd --generate-key --machine-readable) > > uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel früher generiert als bisher (denn die Settings werden erst ausgewertet, wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, ob man bei dieser Variante nicht irgendwann dieselben Keys für verschiedene Router generiert. Für den Aufruf an sich sollte die Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. puh gute Frage, ich hab da leider kaum Ahnung bisher waren die key immer einzigartig und ich habs paar mal probiert. Ist aber natürlich keine große Datenbasis wenn ich jetzt sag so 3-4x vielleicht hab ich es probiert ;) > >> + uci set fff.fastd='fff' >> + uci set fff.fastd.secret="$secret" >> + uci commit fff > > Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem frischen System). Daher wird das auf einem frischen System zu einem Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von 98-configure-fff nach vorne verlegen (was aber wieder diverse Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du ersteres machst. spannend, du solltest recht haben. Ich hab jetzt aber (wie oben erwähnt) mehrfach auch mit -n geflasht, da sollte das ja auch zutreffen. Es hat allerdings funktioniert und das Zeug stand in fff drinnen was ich mir gerade nicht erklären kann. Dennoch unschön und du hast recht. Deine billigste Lösung gefällt mir aber auch nicht. Wie wäre es mit, wir legen eine 15-generate-fff (15 ist jetzt aus der Luft gegriffen, müsste mal gucken was passt) an, machen dort nur ein touch /etc/config/fff und nehmen das touch aus der 98er raus lassen dort aber den Rest drinnen um Nebeneffekte zu vermeiden? Denke das kann dann in ein eigenes Patch und dann kann man es hier so lassen. Was meinst du dazu? > >> +fi >> +uci set fastd.fff.secret="$secret" >> +uci commit fastd >> + >> + > > Eine newline reicht mE. jo Gruß Christian > > Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal diskutieren, testen wird man das schlecht können. > > Grüße > > Adrian > >> [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff >> ln -s /tmp/fastd_fff_peers /etc/fastd/fff/peers >> echo "#!/bin/sh" > /etc/fastd/fff/up.sh >> -- >> 2.11.0
Hallo, > puh gute Frage, ich hab da leider kaum Ahnung bisher waren die key immer > einzigartig und ich habs paar mal probiert. Ist aber natürlich keine > große Datenbasis wenn ich jetzt sag so 3-4x vielleicht hab ich es > probiert ;) Naja, das wird schon reichen. Was passiert wenn ein fastd Server zweimal die gleichen Keys sieht? Werden die als ID verwendet (dann geht’s kaputt) oder nur zur Authentifizierung? Im zweiten Fall wäre es relativ wurscht, solange eine gewissen Grundrandomness verhanden ist (also nicht alle Keys gleich sind). > spannend, du solltest recht haben. Ich hab jetzt aber (wie oben erwähnt) > mehrfach auch mit -n geflasht, da sollte das ja auch zutreffen. Es hat > allerdings funktioniert und das Zeug stand in fff drinnen was ich mir > gerade nicht erklären kann. Dennoch unschön und du hast recht. Wahrscheinlich pfuscht da noch ein anderes Skript dran rum. > Deine billigste Lösung gefällt mir aber auch nicht. Wie wäre es mit, wir legen eine 15-generate-fff (15 ist jetzt aus der Luft gegriffen, müsste mal gucken was passt) an, machen dort nur ein touch /etc/config/fff und nehmen das touch aus der 98er raus lassen dort aber den Rest drinnen um Nebeneffekte zu vermeiden? Denke das kann dann in ein eigenes Patch und dann kann man es hier so lassen. Was meinst du dazu? Prinzipiell ja, so wäre es ordentlich. Ich kuck mir zeitnah mal die uci-defaults Dateien an, das Hauptproblem ist ja, dass wir noch das Upgrade von V1 in 05_configdingsbumms haben. Man sollte sich da schon mal alle Skripte als Ganzes ankucken. Grüße Adrian
Hallo, die fehlende Entropie ist kein Problem. Der Key wird aus urandom generiert. Bleibt also nicht hängen. Gleiche keys wird es nicht geben. Bei fehlender Entropie werden nur schlechtere Zufallszahlen erzeugt. Das ist uns aber egal, da wir damit keine Kryptographie machen. Die noch nicht vorhandene /etc/config/fff ist wirklich unschön. Ein touch finde ich ok an der Stelle. Dass bei den Tests der key in fff gelandet ist, liegt wohl daran, dass das uci-default wegen errorlevel ungleich 0 bem ersten Start nicht gelöscht wird. Und beim zweiten Versuch klappt es dann. Fastd ist das egal, es steht ja srcret=generate drin. Viele Grüße Robert Am 7. Januar 2020 15:07:03 MEZ schrieb Adrian Schmutzler <mail@adrianschmutzler.de>: >Hallo Christian, > >siehe unten. > >> -----Original Message----- >> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf >Of >> Christian Dresel >> Sent: Dienstag, 7. Januar 2020 12:03 >> To: franken-dev@freifunk.net >> Subject: [PATCH v3] fastd: make secret key updatesafe >> >> To use a whitelist easy, it is neccessary to make the fastd key >updatesafe >> This patch safe the key to uci fff and recover it, if a key is after >the update >> available >> >> --- >> Changes in v2: >> - use variable in if >> - remove trailing whitespace >> - remove -q >> --- >> Changes in v3: >> - use only one variable $secret >> --- >> >> Signed-off-by: Christian Dresel <fff@chrisi01.de> >> --- >> .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 >++++++++++- >> 1 file changed, 10 insertions(+), 1 deletion(-) >> >> diff --git >a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> index d53eb43..28384b9 100644 >> --- a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> +++ b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> @@ -15,9 +15,18 @@ uci batch <<EOF >> set fastd.fff.mtu='1426' >> set fastd.fff.on_up="/etc/fastd/fff/up.sh" >> set fastd.fff.secure_handshakes='0' >> - set fastd.fff.secret="generate" >> EOF >> >> +if ! secret=$(uci -q get fff.fastd.secret); then >> + secret=$(/usr/bin/fastd --generate-key --machine-readable) > >uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor >irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel >früher generiert als bisher (denn die Settings werden erst ausgewertet, >wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der >Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns >die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, >ob man bei dieser Variante nicht irgendwann dieselben Keys für >verschiedene Router generiert. Für den Aufruf an sich sollte die >Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. > >> + uci set fff.fastd='fff' >> + uci set fff.fastd.secret="$secret" >> + uci commit fff > >Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem >frischen System). Daher wird das auf einem frischen System zu einem >Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" >zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von >98-configure-fff nach vorne verlegen (was aber wieder diverse >Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du >ersteres machst. > >> +fi >> +uci set fastd.fff.secret="$secret" >> +uci commit fastd >> + >> + > >Eine newline reicht mE. > >Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal >diskutieren, testen wird man das schlecht können. > >Grüße > >Adrian > >> [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff >> ln -s /tmp/fastd_fff_peers /etc/fastd/fff/peers >> echo "#!/bin/sh" > /etc/fastd/fff/up.sh >> -- >> 2.11.0
Hi, ich habe mir das uci-defaults nochmal angeschaut. Da lag ich gestern doch falsch. Es funktioniert wegen 05-config-system-migration. Da wird /etc/config/fff sehr früh angelegt. Trotzdem sollte ein touch rein. Viele Grüße Robert Am 07.01.20 um 22:22 schrieb Robert Langhammer: > Hallo, > die fehlende Entropie ist kein Problem. Der Key wird aus urandom > generiert. Bleibt also nicht hängen. > Gleiche keys wird es nicht geben. Bei fehlender Entropie werden nur > schlechtere Zufallszahlen erzeugt. Das ist uns aber egal, da wir damit > keine Kryptographie machen. > > Die noch nicht vorhandene /etc/config/fff ist wirklich unschön. Ein > touch finde ich ok an der Stelle. > Dass bei den Tests der key in fff gelandet ist, liegt wohl daran, dass > das uci-default wegen errorlevel ungleich 0 bem ersten Start nicht > gelöscht wird. Und beim zweiten Versuch klappt es dann. Fastd ist das > egal, es steht ja srcret=generate drin. > > Viele Grüße > Robert > > > Am 7. Januar 2020 15:07:03 MEZ schrieb Adrian Schmutzler > <mail@adrianschmutzler.de>: > > Hallo Christian, > > siehe unten. > > -----Original Message----- From: franken-dev > [mailto:franken-dev-bounces@freifunk.net] On Behalf Of > Christian Dresel Sent: Dienstag, 7. Januar 2020 12:03 To: > franken-dev@freifunk.net Subject: [PATCH v3] fastd: make > secret key updatesafe To use a whitelist easy, it is > neccessary to make the fastd key updatesafe This patch safe > the key to uci fff and recover it, if a key is after the > update available > ------------------------------------------------------------------------ > Changes in v2: - use variable in if - remove trailing > whitespace - remove -q > ------------------------------------------------------------------------ > Changes in v3: - use only one variable $secret > ------------------------------------------------------------------------ > Signed-off-by: Christian Dresel <fff@chrisi01.de> > ------------------------------------------------------------------------ > .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 > ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) > diff --git > a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > index d53eb43..28384b9 100644 --- > a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > +++ > b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd > @@ -15,9 +15,18 @@ uci batch <<EOF set fastd.fff.mtu='1426' > set fastd.fff.on_up="/etc/fastd/fff/up.sh" set > fastd.fff.secure_handshakes='0' - set > fastd.fff.secret="generate" EOF +if ! secret=$(uci -q get > fff.fastd.secret); then + secret=$(/usr/bin/fastd > --generate-key --machine-readable) > > > uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel früher generiert als bisher (denn die Settings werden erst ausgewertet, wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, ob man bei dieser Variante nicht irgendwann dieselben Keys für verschiedene Router generiert. Für den Aufruf an sich sollte die Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. > > + uci set fff.fastd='fff' + uci set fff.fastd.secret="$secret" > + uci commit fff > > > Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem frischen System). Daher wird das auf einem frischen System zu einem Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von 98-configure-fff nach vorne verlegen (was aber wieder diverse Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du ersteres machst. > > +fi +uci set fastd.fff.secret="$secret" +uci commit fastd + + > > > Eine newline reicht mE. > > Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal diskutieren, testen wird man das schlecht können. > > Grüße > > Adrian > > [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff ln -s > /tmp/fastd_fff_peers /etc/fastd/fff/peers echo "#!/bin/sh" > > /etc/fastd/fff/up.sh -- 2.11.0 > > > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Hi Robert du hast recht. Was haltet ihr davon, wenn man aus den ganzen files dieses touch /etc/config/fff rausnimmt und die file mit 02-create-fff anlegt? In dieser file wird dann nie was anderes geschehen und ist wirklich nur fürs anlegen da. Man braucht die /etc/config/fff ja so oder so und dann kann man sie auch schon sehr früh anlegen, es ist von nix anderen Abhängig und darf auch als allererstes gemacht werden, dann ist sie wenigstens immer da wenn man sie braucht. In unseren Fall wäre das dann das allererste was im uci default pasiert, aktuell fängt OpenWRT mit 03 an und unser erstes Script ist das 05-config-system-migration. Das ganze ins package fff-config und fastd bräuchte dann dorthin eigentlich ne Abhängigkeit oder? Meiner Meinung nach wäre das der sauberste Weg. Gruß Christian On 09.01.20 00:39, robert wrote: > Hi, > > ich habe mir das uci-defaults nochmal angeschaut. Da lag ich gestern > doch falsch. Es funktioniert wegen 05-config-system-migration. Da wird > /etc/config/fff sehr früh angelegt. Trotzdem sollte ein touch rein. > > Viele Grüße > Robert > > Am 07.01.20 um 22:22 schrieb Robert Langhammer: >> Hallo, >> die fehlende Entropie ist kein Problem. Der Key wird aus urandom >> generiert. Bleibt also nicht hängen. >> Gleiche keys wird es nicht geben. Bei fehlender Entropie werden nur >> schlechtere Zufallszahlen erzeugt. Das ist uns aber egal, da wir damit >> keine Kryptographie machen. >> >> Die noch nicht vorhandene /etc/config/fff ist wirklich unschön. Ein >> touch finde ich ok an der Stelle. >> Dass bei den Tests der key in fff gelandet ist, liegt wohl daran, dass >> das uci-default wegen errorlevel ungleich 0 bem ersten Start nicht >> gelöscht wird. Und beim zweiten Versuch klappt es dann. Fastd ist das >> egal, es steht ja srcret=generate drin. >> >> Viele Grüße >> Robert >> >> >> Am 7. Januar 2020 15:07:03 MEZ schrieb Adrian Schmutzler >> <mail@adrianschmutzler.de>: >> >> Hallo Christian, >> >> siehe unten. >> >> -----Original Message----- From: franken-dev >> [mailto:franken-dev-bounces@freifunk.net] On Behalf Of >> Christian Dresel Sent: Dienstag, 7. Januar 2020 12:03 To: >> franken-dev@freifunk.net Subject: [PATCH v3] fastd: make >> secret key updatesafe To use a whitelist easy, it is >> neccessary to make the fastd key updatesafe This patch safe >> the key to uci fff and recover it, if a key is after the >> update available >> ------------------------------------------------------------------------ >> Changes in v2: - use variable in if - remove trailing >> whitespace - remove -q >> ------------------------------------------------------------------------ >> Changes in v3: - use only one variable $secret >> ------------------------------------------------------------------------ >> Signed-off-by: Christian Dresel <fff@chrisi01.de> >> ------------------------------------------------------------------------ >> .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 >> ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) >> diff --git >> a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> index d53eb43..28384b9 100644 --- >> a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> +++ >> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> @@ -15,9 +15,18 @@ uci batch <<EOF set fastd.fff.mtu='1426' >> set fastd.fff.on_up="/etc/fastd/fff/up.sh" set >> fastd.fff.secure_handshakes='0' - set >> fastd.fff.secret="generate" EOF +if ! secret=$(uci -q get >> fff.fastd.secret); then + secret=$(/usr/bin/fastd >> --generate-key --machine-readable) >> >> >> uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel früher generiert als bisher (denn die Settings werden erst ausgewertet, wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, ob man bei dieser Variante nicht irgendwann dieselben Keys für verschiedene Router generiert. Für den Aufruf an sich sollte die Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. >> >> + uci set fff.fastd='fff' + uci set fff.fastd.secret="$secret" >> + uci commit fff >> >> >> Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem frischen System). Daher wird das auf einem frischen System zu einem Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von 98-configure-fff nach vorne verlegen (was aber wieder diverse Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du ersteres machst. >> >> +fi +uci set fastd.fff.secret="$secret" +uci commit fastd + + >> >> >> Eine newline reicht mE. >> >> Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal diskutieren, testen wird man das schlecht können. >> >> Grüße >> >> Adrian >> >> [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff ln -s >> /tmp/fastd_fff_peers /etc/fastd/fff/peers echo "#!/bin/sh" > >> /etc/fastd/fff/up.sh -- 2.11.0 >> >> >> -- >> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Hallo, das Skript 05-config-system-migration ist dazu da, aus einer alten Firmware, die die Config noch in /etc/config/system enthält, die "neue" Datei /etc/config/fff zu machen. Dafür prüft das Skript unter anderem, ob es /etc/config/fff schon gibt. Es macht daher konzeptionell wenig Sinn, diese Datei vorher schon anzulegen (auch wenn es mit einem reinen touch und dem -s technisch funktionieren würde). In meiner Firmware habe ich hier ein Skript 10-setup-fff, dass die Datei anlegt (falls nicht schon geschehen) und sie auch gleich mit Standardwerten füllt, damit man weiß, was man einstellen kann: https://github.com/adrianschmutzler/fff-firmware/blob/mainline/src/packages/fff/fff-config/files/etc/uci-defaults/10-setup-fff Diese Skript könnte man relativ einfach in die offizielle FW portieren (es fallen dann halt meine ganzen Spezialsettings wieder raus, nur das Setzen des Hostnamen bliebe dort. Diese Standardwerte könnten dann durch andere, spätere uci defaults Skripte verändert und ergänzt werden. Wir haben also folgenden Ablauf: 05-... Migration alter /etc/config/system 10-... Erzeugen der Datei und Setzen von Default-Werten (falls nicht vorhanden nach Upgrade mit Erhalt der Config) xx-... Ergänzen und Verändern der Werte durch Packages (inkl. dem was 98-configure-fff macht, dort fällt der touch raus) Meines Erachtens entspricht dies im Wesentlichen Christians Konzept, nur dass wir nicht vor der Migration sitzen und ich das Ganze und das Setzen von Standardwerten ergänzt habe. Ich schicke mal einen Patch dazu. Des Weiteren bin ich nach wie vor der Meinung, dass wir das Migrations-Skript (wurde mit der letzten V1-Firmware eingeführt) inzwischen entfernen sollten. Wer noch von 201701xx oder älter updatet, kann ruhig die Konfiguration verlieren. Grüße Adrian From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Christian Dresel Sent: Donnerstag, 9. Januar 2020 13:06 To: robert <rlanghammer@web.de>; franken-dev@freifunk.net Subject: Re: [PATCH v3] fastd: make secret key updatesafe Hi Robert du hast recht. Was haltet ihr davon, wenn man aus den ganzen files dieses touch /etc/config/fff rausnimmt und die file mit 02-create-fff anlegt? In dieser file wird dann nie was anderes geschehen und ist wirklich nur fürs anlegen da. Man braucht die /etc/config/fff ja so oder so und dann kann man sie auch schon sehr früh anlegen, es ist von nix anderen Abhängig und darf auch als allererstes gemacht werden, dann ist sie wenigstens immer da wenn man sie braucht. In unseren Fall wäre das dann das allererste was im uci default pasiert, aktuell fängt OpenWRT mit 03 an und unser erstes Script ist das 05-config-system-migration. Das ganze ins package fff-config und fastd bräuchte dann dorthin eigentlich ne Abhängigkeit oder? Meiner Meinung nach wäre das der sauberste Weg. Gruß Christian On 09.01.20 00:39, robert wrote: > Hi, > > ich habe mir das uci-defaults nochmal angeschaut. Da lag ich gestern > doch falsch. Es funktioniert wegen 05-config-system-migration. Da wird > /etc/config/fff sehr früh angelegt. Trotzdem sollte ein touch rein. > > Viele Grüße > Robert > > Am 07.01.20 um 22:22 schrieb Robert Langhammer: >> Hallo, >> die fehlende Entropie ist kein Problem. Der Key wird aus urandom >> generiert. Bleibt also nicht hängen. >> Gleiche keys wird es nicht geben. Bei fehlender Entropie werden nur >> schlechtere Zufallszahlen erzeugt. Das ist uns aber egal, da wir damit >> keine Kryptographie machen. >> >> Die noch nicht vorhandene /etc/config/fff ist wirklich unschön. Ein >> touch finde ich ok an der Stelle. >> Dass bei den Tests der key in fff gelandet ist, liegt wohl daran, dass >> das uci-default wegen errorlevel ungleich 0 bem ersten Start nicht >> gelöscht wird. Und beim zweiten Versuch klappt es dann. Fastd ist das >> egal, es steht ja srcret=generate drin. >> >> Viele Grüße >> Robert >> >> >> Am 7. Januar 2020 15:07:03 MEZ schrieb Adrian Schmutzler >> <mail@adrianschmutzler.de>: >> >> Hallo Christian, >> >> siehe unten. >> >> -----Original Message----- From: franken-dev >> [mailto:franken-dev-bounces@freifunk.net] On Behalf Of >> Christian Dresel Sent: Dienstag, 7. Januar 2020 12:03 To: >> franken-dev@freifunk.net Subject: [PATCH v3] fastd: make >> secret key updatesafe To use a whitelist easy, it is >> neccessary to make the fastd key updatesafe This patch safe >> the key to uci fff and recover it, if a key is after the >> update available >> ------------------------------------------------------------------------ >> Changes in v2: - use variable in if - remove trailing >> whitespace - remove -q >> ------------------------------------------------------------------------ >> Changes in v3: - use only one variable $secret >> ------------------------------------------------------------------------ >> Signed-off-by: Christian Dresel <fff@chrisi01.de> >> ------------------------------------------------------------------------ >> .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 >> ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) >> diff --git >> a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> index d53eb43..28384b9 100644 --- >> a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> +++ >> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >> @@ -15,9 +15,18 @@ uci batch <<EOF set fastd.fff.mtu='1426' >> set fastd.fff.on_up="/etc/fastd/fff/up.sh" set >> fastd.fff.secure_handshakes='0' - set >> fastd.fff.secret="generate" EOF +if ! secret=$(uci -q get >> fff.fastd.secret); then + secret=$(/usr/bin/fastd >> --generate-key --machine-readable) >> >> >> uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel früher generiert als bisher (denn die Settings werden erst ausgewertet, wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, ob man bei dieser Variante nicht irgendwann dieselben Keys für verschiedene Router generiert. Für den Aufruf an sich sollte die Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. >> >> + uci set fff.fastd='fff' + uci set fff.fastd.secret="$secret" >> + uci commit fff >> >> >> Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem frischen System). Daher wird das auf einem frischen System zu einem Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von 98-configure-fff nach vorne verlegen (was aber wieder diverse Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du ersteres machst. >> >> +fi +uci set fastd.fff.secret="$secret" +uci commit fastd + + >> >> >> Eine newline reicht mE. >> >> Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal diskutieren, testen wird man das schlecht können. >> >> Grüße >> >> Adrian >> >> [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff ln -s >> /tmp/fastd_fff_peers /etc/fastd/fff/peers echo "#!/bin/sh" > >> /etc/fastd/fff/up.sh -- 2.11.0 >> >> >> -- >> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Hallo Adrian On 09.01.20 13:26, Adrian Schmutzler wrote: > Hallo, > > das Skript 05-config-system-migration ist dazu da, aus einer alten Firmware, die die Config noch in /etc/config/system enthält, die "neue" Datei /etc/config/fff zu machen. > > Dafür prüft das Skript unter anderem, ob es /etc/config/fff schon gibt. Es macht daher konzeptionell wenig Sinn, diese Datei vorher schon anzulegen (auch wenn es mit einem reinen touch und dem -s technisch funktionieren würde). > > In meiner Firmware habe ich hier ein Skript 10-setup-fff, dass die Datei anlegt (falls nicht schon geschehen) und sie auch gleich mit Standardwerten füllt, damit man weiß, was man einstellen kann: > > https://github.com/adrianschmutzler/fff-firmware/blob/mainline/src/packages/fff/fff-config/files/etc/uci-defaults/10-setup-fff > > Diese Skript könnte man relativ einfach in die offizielle FW portieren (es fallen dann halt meine ganzen Spezialsettings wieder raus, nur das Setzen des Hostnamen bliebe dort. > > Diese Standardwerte könnten dann durch andere, spätere uci defaults Skripte verändert und ergänzt werden. > > Wir haben also folgenden Ablauf: > > 05-... Migration alter /etc/config/system > 10-... Erzeugen der Datei und Setzen von Default-Werten (falls nicht vorhanden nach Upgrade mit Erhalt der Config) > xx-... Ergänzen und Verändern der Werte durch Packages (inkl. dem was 98-configure-fff macht, dort fällt der touch raus) > > Meines Erachtens entspricht dies im Wesentlichen Christians Konzept, nur dass wir nicht vor der Migration sitzen und ich das Ganze und das Setzen von Standardwerten ergänzt habe. so verstehe ich deine Erklärung auch gerade, wobei mir eigentlich mein Konzept besser gefällt aber damit kann ich auch leben und wenns schon ein fertiges Patch gibt dann... > > Ich schicke mal einen Patch dazu. ...sehr gerne, dann muss ich nicht :P > > Des Weiteren bin ich nach wie vor der Meinung, dass wir das Migrations-Skript (wurde mit der letzten V1-Firmware eingeführt) inzwischen entfernen sollten. Wer noch von 201701xx oder älter updatet, kann ruhig die Konfiguration verlieren. Wenn das wirklich nur v1 Settings migriert und schon bei einem Update von der allerersten v2 Release nicht mehr gebraucht wird, würde ich hier zustimmen, ob es so ist weiß ich nicht. Anderseits tuts auch nicht wirklich weh von daher will ich da jetzt nicht hindrängen aber wenns wer los werden will -> nur zu. Gruß Christian > > Grüße > > Adrian > > > > From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Christian Dresel > Sent: Donnerstag, 9. Januar 2020 13:06 > To: robert <rlanghammer@web.de>; franken-dev@freifunk.net > Subject: Re: [PATCH v3] fastd: make secret key updatesafe > > Hi Robert > du hast recht. > Was haltet ihr davon, wenn man aus den ganzen files dieses touch > /etc/config/fff rausnimmt und die file mit 02-create-fff anlegt? In > dieser file wird dann nie was anderes geschehen und ist wirklich nur > fürs anlegen da. Man braucht die /etc/config/fff ja so oder so und dann > kann man sie auch schon sehr früh anlegen, es ist von nix anderen > Abhängig und darf auch als allererstes gemacht werden, dann ist sie > wenigstens immer da wenn man sie braucht. In unseren Fall wäre das dann > das allererste was im uci default pasiert, aktuell fängt OpenWRT mit 03 > an und unser erstes Script ist das 05-config-system-migration. Das ganze > ins package fff-config und fastd bräuchte dann dorthin eigentlich ne > Abhängigkeit oder? > Meiner Meinung nach wäre das der sauberste Weg. > Gruß > Christian > On 09.01.20 00:39, robert wrote: >> Hi, >> >> ich habe mir das uci-defaults nochmal angeschaut. Da lag ich gestern >> doch falsch. Es funktioniert wegen 05-config-system-migration. Da wird >> /etc/config/fff sehr früh angelegt. Trotzdem sollte ein touch rein. >> >> Viele Grüße >> Robert >> >> Am 07.01.20 um 22:22 schrieb Robert Langhammer: >>> Hallo, >>> die fehlende Entropie ist kein Problem. Der Key wird aus urandom >>> generiert. Bleibt also nicht hängen. >>> Gleiche keys wird es nicht geben. Bei fehlender Entropie werden nur >>> schlechtere Zufallszahlen erzeugt. Das ist uns aber egal, da wir damit >>> keine Kryptographie machen. >>> >>> Die noch nicht vorhandene /etc/config/fff ist wirklich unschön. Ein >>> touch finde ich ok an der Stelle. >>> Dass bei den Tests der key in fff gelandet ist, liegt wohl daran, dass >>> das uci-default wegen errorlevel ungleich 0 bem ersten Start nicht >>> gelöscht wird. Und beim zweiten Versuch klappt es dann. Fastd ist das >>> egal, es steht ja srcret=generate drin. >>> >>> Viele Grüße >>> Robert >>> >>> >>> Am 7. Januar 2020 15:07:03 MEZ schrieb Adrian Schmutzler >>> <mail@adrianschmutzler.de>: >>> >>> Hallo Christian, >>> >>> siehe unten. >>> >>> -----Original Message----- From: franken-dev >>> [mailto:franken-dev-bounces@freifunk.net] On Behalf Of >>> Christian Dresel Sent: Dienstag, 7. Januar 2020 12:03 To: >>> franken-dev@freifunk.net Subject: [PATCH v3] fastd: make >>> secret key updatesafe To use a whitelist easy, it is >>> neccessary to make the fastd key updatesafe This patch safe >>> the key to uci fff and recover it, if a key is after the >>> update available >>> ------------------------------------------------------------------------ >>> Changes in v2: - use variable in if - remove trailing >>> whitespace - remove -q >>> ------------------------------------------------------------------------ >>> Changes in v3: - use only one variable $secret >>> ------------------------------------------------------------------------ >>> Signed-off-by: Christian Dresel <fff@chrisi01.de> >>> ------------------------------------------------------------------------ >>> .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 >>> ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) >>> diff --git >>> a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >>> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >>> index d53eb43..28384b9 100644 --- >>> a/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >>> +++ >>> b/src/packages/fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd >>> @@ -15,9 +15,18 @@ uci batch <<EOF set fastd.fff.mtu='1426' >>> set fastd.fff.on_up="/etc/fastd/fff/up.sh" set >>> fastd.fff.secure_handshakes='0' - set >>> fastd.fff.secret="generate" EOF +if ! secret=$(uci -q get >>> fff.fastd.secret); then + secret=$(/usr/bin/fastd >>> --generate-key --machine-readable) >>> >>> >>> uci-defaults wird sehr früh im Bootprozess ausgelöst, noch lange bevor irgendein Dienst startet. Mit dieser Zeile wird demnach der Key viel früher generiert als bisher (denn die Settings werden erst ausgewertet, wenn fastd startet; S=50 glaube ich). Das heißt, die Entropy an der Stelle wird quasi Null sein. Wenn ich mich richtig erinnere, ist uns die Entropy ja ziemlich egal, aber ich kann nicht wirklich abschätzen, ob man bei dieser Variante nicht irgendwann dieselben Keys für verschiedene Router generiert. Für den Aufruf an sich sollte die Tatsache, dass der Dienst noch nicht läuft ja wahrscheinlich egal sein. >>> >>> + uci set fff.fastd='fff' + uci set fff.fastd.secret="$secret" >>> + uci commit fff >>> >>> >>> Die /etc/config/fff wird erst in 98-configure-fff generiert (auf einem frischen System). Daher wird das auf einem frischen System zu einem Fehler führen. Die billige Lösung wäre hier ein "touch /etc/config/fff" zu ergänzen, wenn man es richtig machen will müsste ggf. den Start von 98-configure-fff nach vorne verlegen (was aber wieder diverse Nebeneffekte haben könnte.) Ich denke, erstmal reicht es, wenn du ersteres machst. >>> >>> +fi +uci set fastd.fff.secret="$secret" +uci commit fastd + + >>> >>> >>> Eine newline reicht mE. >>> >>> Ansonsten sieht das gut aus. Das mit der Entropy sollte man nochmal diskutieren, testen wird man das schlecht können. >>> >>> Grüße >>> >>> Adrian >>> >>> [ ! -d /etc/fastd/fff ] && mkdir -p /etc/fastd/fff ln -s >>> /tmp/fastd_fff_peers /etc/fastd/fff/peers echo "#!/bin/sh" > >>> /etc/fastd/fff/up.sh -- 2.11.0 >>> >>> >>> -- >>> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Hallo nochmal, ich habe gerade festgestellt, dass ich Unsinn geschrieben habe: Der Codeflow in 05-config-system-migration stellt zu jedem Zeitpunkt sicher, dass /etc/config/fff existiert. Für deinen Patch brauchen wir also überhaupt keine weitere Änderung und auch kein weiteres touch (deshalb hat er auch bei deinen Tests einfach funktioniert). Meine 10-setup-fff hat nur den Zweck, alle Optionen mit Standardwerten in /etc/config/fff reinzuschreiben, sodass man die Optionen nicht nachkucken muss. Die /etc/config/fff wird seit der 20180303-alpha verwendet, also in allen v2-Firmwares. Grüße Adrian
hi On 09.01.20 13:46, Adrian Schmutzler wrote: > Hallo nochmal, > > ich habe gerade festgestellt, dass ich Unsinn geschrieben habe: > > Der Codeflow in 05-config-system-migration stellt zu jedem Zeitpunkt sicher, dass /etc/config/fff existiert. Für deinen Patch brauchen wir also überhaupt keine weitere Änderung und auch kein weiteres touch (deshalb hat er auch bei deinen Tests einfach funktioniert). das ist genau das, was Robert geschrieben hat. Hab das jetzt nicht so verstanden das du es anders verstanden hast (jetzt wirds komplizert). Aber ja ich seh das genauso das mein Patch soweit richtig ist. Wenn man deine Änderung einpflegt sogar "sauber" richtig ist. Das einzige was man noch diskutieren müsste, dependecies von fff-fastd zu fff-config? > > Meine 10-setup-fff hat nur den Zweck, alle Optionen mit Standardwerten in /etc/config/fff reinzuschreiben, sodass man die Optionen nicht nachkucken muss. > > Die /etc/config/fff wird seit der 20180303-alpha verwendet, also in allen v2-Firmwares. dann kann sie wegen mir raus, aber warte da mal noch auf weitere Meinungen was andere so denken. Gruß Christian > > Grüße > > Adrian >
> Das einzige was man noch diskutieren müsste, dependecies von fff-fastd > zu fff-config? Spricht mMn nichts dagegen.
To use a whitelist easy, it is neccessary to make the fastd key updatesafe This patch safe the key to uci fff and recover it, if a key is after the update available --- Changes in v2: - use variable in if - remove trailing whitespace - remove -q --- Changes in v3: - use only one variable $secret --- Signed-off-by: Christian Dresel <fff@chrisi01.de> --- .../fff/fff-fastd/files/etc/uci-defaults/55_fff-fastd | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)