[PATCH v3] fastd: make secret key updatesafe

[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 at adrianschmutzler.de>:
>Hallo Christian,
>
>siehe unten.
>
>> -----Original Message-----
>> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
>Of
>> Christian Dresel
>> Sent: Dienstag, 7. Januar 2020 12:03
>> To: franken-dev at 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 at 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.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20200107/2cf30836/attachment.html>