Jak vypnout IPv6 privacy extensions na novém Androidu
Pod stromečkem jsem rozbalil nový mobil s Androidem 4.4 Kitkat. Bohužel musím konstatovat, že ani zcela nová verze operačního systému, která v USA pracuje v IPv6-only, pořád kašle na dodržování RFC 4941, se kterým byl Android až do verze 4 konformní:
Použití dočasných adres (pro ochranu soukromí) může způsobovat nečekané obtíže s některými aplikacemi. Servery mohou odmítnout spojení od klientů bez reverzního DNS záznamu. Navíc se některé aplikace nemusí chovat robustně pokud dočasná adresa vyprší před ukončením aplikace, nebo pokud otevře více spojení a očekává, že všechny budou používat stejné adresy. Z toho důvodu BY MĚLY (SHOULD) být dočasné adresy ve výchozím stavu zakázány.
Normativní jazyk zde používá slovo SHOULD, které se obvykle překládá jako: „Měli byste, pokud nemáte skutečně závažný důvod to nedělat.“ Přesto v podstatě veškeré aktuální platformy implementující IPv6 (počínaje Windows, přes Mac, až po nejnovější linuxové distribuce) tento příkaz porušují a dočasné adresy zapínají automaticky. To bych jim ani neměl za zlé, přeci jen se tu a tam objeví někdo s názorem, že vyzrazení MAC adresy do Internetu je ten nejstrašnější zásah do soukromí, co existuje. I když tento názor nesdílím, jsem ochoten takovéto výchozí nastavení strpět. Co však již nestrpím, je přímý rozpor s jinou částí výše uvedeného RFC:
Zařízení implementující dočasné adresy pro ochranu soukromí MUSÍ poskytovat způsob, kterým může koncový uživatel explicitně povolit nebo zakázat použití dočasných adres.
Zatímco Windows tuhle podmínku beze zbytku splňují už od experimentálního IPv6 stacku ve verzi XP, na Linuxu založené systémy s tím mají překvapivě dost velký problém. Viděl jsem například distribuci s Network Managerem, který po každém připojení k síti automaticky zapnul dočasné adresy, aniž by tato volba byla někde uživatelsky editovatelná. Uživatel sice mohl nastavení změnit příslušným voláním sysctl, Network Manager jej však při příštím spojení opět přepsal.
Smutné je, že vývojáři systému Android se zachovali stejně špatně. Tamější správce sítí při každém úspěšném připojení k síti zapíše dvojku do souboru /proc/sys/net/ipv6/conf/<rozhraní>/use_tempaddr. Čekal jsem, že aspoň nejnovější verze nabídne někde hluboko v menu možnost tuto volbu vypnout, ale není tomu tak. Chyby jsou stále nahlášeny (ještě v diskuzi zde), kód se však moc nemění. Nezbývá tedy než vyhrnout si rukávy a upravit si systém svépomocí.
Protože jsem se chtěl vyhnout překompilovávání celého OS, vydal jsem se cestou přímého patchování binárky. Vlastní zapnutí obstarává program /system/bin/netd. Když v něm budete hledat klíčové slovo use_tempaddr, najdete jej na hromadě spolu ostatními texty:
$ hexdump -C netd … 000111c0 79 00 25 73 2f 25 73 2f 25 73 00 64 69 73 61 62 |y.%s/%s/%s.disab| 000111d0 6c 65 5f 69 70 76 36 00 32 00 75 73 65 5f 74 65 |le_ipv6.2.use_te| 000111e0 6d 70 61 64 64 72 00 2e 00 2e 2e 00 61 6c 6c 00 |mpaddr......all.| …
Když jsem před textem uviděl samostatný řetězec s dvojkou, zajásal jsem, že to je ono, že to je ta dvojka, která se do souboru zapíše. Přepsal jsem ji tedy na nulu a restartoval. Operační systém naběhl bez problému a na rozhraní skutečně nebyla dočasná IPv6 adresa. Mělo to však drobnou vadu na kráse, na rozhraní totiž nebyla žádná IPv6 adresa. :) Jak je to možné? Může za to optimalizace kompilátoru. Stejná dvojka, která se zapisuje do souboru use_tempaddr se totiž také zapisuje do souboru accept_ra, kde zapíná příjem RA i v režimu směrovače. Když jsem ji přepsal na nulu, kromě vypnutí dočasných adres jsem tedy také zároveň vypnul příjem veškerých RA. Tudy cesta nevede.
Poněkud méně čistá cesta spočívá v přepsání řetězce use_tempaddr za jiný, neexistující název souboru. Při pokusu o zápis do něj dojde k chybě, systém se s chybou bez problému vyrovná. Eventuálně je možné přepsat řetězec za accept_ra, do kterého by se dvojka zapsala dvakrát po sobě, což by nebylo na škodu.
Postup úpravy krok za krokem
- Výchozím předpokladem je telefon s oprávněním roota, USB laděním. Ten by měl být připojen k PC vybaveném utilitkou
adb(balíkandroid-tools). Také se hodí zálohovat veškerá data pro případ, že se něco nepovede. - Z telefonu stáhneme původní binárku a zazálohujeme ji:
$ adb pull /system/bin/netd $ cp netd netd.orig
- Pomocí hexeditoru v binárce nalezneme řetězec
use_tempaddra přepíšeme na libovolnou hodnotu. Je také dobré zkontrolovat, že upravená binárka má stejnou velikost jako před úpravou a že se liší skutečně jen v obsahu zmíněného řetězce. Například Vim mi soustavně binárku prodlužoval o konec řádku. - Upravenou binárku nahrajeme na dočasné umístění v telefonu:
$ adb push netd /sdcard/netd
- Na telefonu přepíšeme původní binárku a opravíme práva:
$ adb shell user@phone$ su root@phone# mount -o remount,rw /system root@phone# cp /system/bin/netd /system/bin/netd.orig root@phone# rm /system/bin/netd root@phone# cp /sdcard/netd /system/bin/netd root@phone# chown root:shell /system/bin/netd* root@phone# chmod 755 /system/bin/netd* root@phone# exit user@phone$ exit
- Restartujeme telefon:
$ adb reboot
Závěrem mi nezbývá než vyjádřit přání, že se někdo v Google konečně chytne za nos a chybu opraví systémově. Můžete tomu možná pomocí, přidáte-li hvězdičky k výše uvedeným hlášením chyb.
Přeji vše dobré v novém roce.
-
Související články na blogu Oskarův Weblog @root
-
Opravte si e-defekt svépomocí 6. 3. 2014 11:53
-
Jak zvětšit disk virtuálního serveru a nepřijít o data 19. 9. 2013 13:43
-
Podivné chování EURidu s DNSSEC 13. 8. 2013 15:14
-
Měkké dárky na poslední chvíli 18. 12. 2012 0:01
-
E-mailové služby neběží po šestce 8. 6. 2012 14:43
-
Bezpečné uspání s šifrovaným diskem 11. 5. 2012 14:52
-
-
Související články na ostatních blozích
-
Restart sítě v Debianu: jak správně na to 19. 11. 2012 22:27
-
Křepelkův syndrom 20. 7. 2008 1:03
-
ZABBIX a neočekávaný nárůst velikosti databáze 4. 9. 2023 12:20
-
Recenze: Chromebook Education 11 3189 2-in-1 (2017) 30. 12. 2018 1:37
-
Ebook: Ze života správce linuxových serverů 29. 5. 2018 7:44
-
Co se mi osvědčilo v roce 2017 31. 12. 2017 13:45
-
-
Související články na serveru Root.cz
-
Fedora upouští od balíčků X11, FreeBSD zrychluje cyklus vydávání 22. 7. 2024 0:00
-
Lepší podpora Snapdragon X1 Elite, nový TRIM pro XFS 21. 7. 2024 0:00
-
Zavaděč už nepotřebujeme, startujte rovnou jádro, říkají vývojáři Red Hatu 19. 7. 2024 0:00
-
Peppermint OS má novou edici, Red Hat se zbavuje Grubu 16. 7. 2024 0:00
-
Postřehy z bezpečnosti: Signal pod palbou a lepší arzenál APT41 15. 7. 2024 0:00
-
Novinky pro Linux 6.11: nejen atomický zápis na NVMe a throttlování CPU Intel 12. 7. 2024 0:00
-
-
Libor (neregistrovaný)
Pokud vím, tak Win používá RFC 4941 adresy ve výchozí konfiguraci od Vista. Apple v aktuální verzi Mac OS/ iOS preferuje RFC 4941 adresy.
Situace došla až tak daleko, že RFC 6724 [Default Address Selection for Internet Protocol Version 6 (IPv6) - proposed standard] mění preferenci adres:
"For source address selection, temporary addresses [RFC4941] are preferred over public addresses."
"This default is intended to
address privacy concerns as discussed in [RFC4941] but introduces a
risk of applications potentially failing due to the relatively short
lifetime of temporary addresses or due to the possibility of the
reverse lookup of a temporary address either failing or returning a
randomized name. Implementations for which application compatibility
considerations outweigh these privacy concerns MAY reverse the sense
of this rule and by default prefer public addresses over temporary
addresses."Možná si někteří počítačoví nadšenci RFC 4941 vypnou, ale s větším rozšířením IPv6 se budou muset přizpůsobit aplikace běžným uživatelům. Windows, Apple, Android a User-friendly linuxové distribuce (Ubuntu, Fedora ...) budou dále v základu pracovat s RFC 4941.
-
Ondřej Caletka (neregistrovaný)
[1]. Ano, bohužel. Jen bych čekal, že implementátoři budou právě z řad těch počítačových nadšenců a proto budou trvat na tom, aby tahle funkce šla uživatelsky vypnout, zvlášť když to RFC nařizuje. Nehledě na to, že implementace dočasných adres přinejmenším v Linuxovém kernelu rozhodně není plnohodnotná (Pavlix by jistě mohl vyprávět :) ). Údajně, když se kernel rozhodne, že starou dočasnou adresu odstraní, prostě jí vymaže, bez ohledu na probíhající spojení (která se tedy rozpadnou).
-
m (neregistrovaný)
[3]: Windows funguje presne rovnako, stara v systeme zostava a pouziva sa pre existujuce spojenia, nova sa pouziva na nove spojenia. Moze vsak nastat situacia, ze v systeme mate niekolko (aj desiatok) IPv6 adries a rozne programy pouzivaju starsie alebo novsie podla toho ako zostavaju nadviazane spojenia z casu tej-ktorej IPv6 adresy..
-
Ondřej Caletka (neregistrovaný)
[3]. Ano, adresa se označí jako deprecated, takže by se s ní nové spojení zahajovat nemělo. Ale po určité době od označení adresy jako deprecated je adresa kernelem natvrdo odstraněna a pokud ji stále nějaká aplikace používala (například otevřela spojení před vypršením adresy), spojení spadne. Je to ale spíše teoretický problém, v praxi jsou několik hodin trvající spojení výjimečné a aplikace, které je používají, se jsou obvykle schopny spojení automaticky obnovovat.
-
Pavel Šimerda (neregistrovaný)
[3] V době, kdy mě na školení požádali toto otestovat jsme používali tuším Debian 6. Pravda je, že od té doby jsem test neopakoval, ale ani jsem zatím neslyšel, že by se ta chyba řešila. Při normálním testovacím provozu to člověk jen tak nezjistí, je potřeba upravit časování v router advertisements tak, aby měl test vůbec smysl. Budu muset někdy test zopakovat s novým jádrem. A mimochodem to, co píše Ondra taky platí, ve chvíli, kdy se dočasná adresa zruší úplně, tak spojení padne (viz [5]).
Vtip je v tom, že kernelová autokonfigurace je celkově tak debilní (neumí nic jiného než psát přímo do aktivních kernelových tabulek), že její vlastnosti stejně za chvíli nebudou zajímavé. NetworkManager 0.9.10 už kernelovou autokonfiguraci používat nebude a všechny ostatní síťové konfigurátory, které budou chtít fungovat dobře s více sítěmi, nedej bože VPN, se k tomu nejspíše postaví stejně.
-
Ondřej Caletka (neregistrovaný)
[8]. Pokud jsem dobře pochopil to RFC 4941, tak tam se finální odstranění adresy nenařizuje, je tam pouze zmínka, že platforma MŮŽE odstranit zavrženou IP adresu poté, co ji vyšší vrstvy nepoužívají s tím, že zjišťování používanosti adresy je naznačeno v kapitole „Future Work“. To chápu tak, že platforma, která nezjišťuje, zda adresu používají vyšší vrstvy (jako třeba linux) by adresy z rozhraní mazat neměla nikdy. Pak by SSH spojení běželo třeba rok ze stále stejné zavržené adresy.
-
Pavel Šimerda (neregistrovaný)
[9] Tak hluboko jsem to nestudoval, ale měl jsem dojem, že linux používá preferred lifetime a valid lifetime. Bohužel ty IPv6 standardy nejsou tak úplně moc sladěné. Nicméně je potřeba nezapomínat, že u nového NetworkManageru a do budoucna i u jiného software musíš počítat s tím, že se implementace dělí mezi kernel a userspace, takže by bylo dobré udržovat nějaký zdroj ohledně best practices a implementace testovat.
-
j (neregistrovaný)
Technicky v odstraneni zneplatneny adresy nevidim az takovej problem - pokud je tam nejaky okno, kdy maji appky sanci se stim vyporadat. Podle me by stim mely pocitat prave aplikace, a tam kde si zjistuji adresu, by se mely zaroven zjistit, jak dlouho jeste bude platit. Ostatne, je na aplikaci zda si rekne o docasnou nebo trvalou IP. Znam par takovych (napr filezilla klient), ktery natvrdo berou trvalou (coz prozmenu rozbiji koncepci privacy ext)
-
Richard (neregistrovaný)
Dobrý den.
Přiznám se rovnou, že tomu, o čem zde píšete, moc nerozumím a navíc k androidu jsem se prvně dostal asi před třemi dny nákupem dvou telefonů a jednoho tabletu pro děti. Ale je mi jasné, že to úzce souvisí s mým problémem, a sice s tím používáním dočasných MAC adres. Zatím jsem se s tím nikde nesetkal a jelikož doma v síti adresy filtrujeme, resp. přístup do sítě je možný jen pro přednastavené, povolené MAC adresy, pak s touhle vychytávkou je to dost pakárna. Zajímavé ovšem je, že to takhle dělá jen jeden z těch telefonů a tablet, zatím co ten druhý telefon si svou adresu normálně drží.
A tak Vás prosím o radu, jestli dnes už neexistuje nějaké jiné, jednodušší řešení, jak těm přístrojům vysvětlit, aby používali jen jednu, stále stejnou MAC adresu, a pokud je ta zhora popisovaná cesta jediná, tak jestli byste mi s tím někdo nebyl ochoten pomoci, protože tohle sám asi fakt nedám ...
Za případné reakce předem díky moc! -
Ondřej Caletka (neregistrovaný)
[13]. Nevím o tom, že by nějaký Android náhodně měnil MAC adresu; zatím u všech, co mi prošli rukama byla MAC adresa statická a zobrazená v menu Pokročilé nastavení Wi-Fi. Blogpost mluví o dynamicky se měnících IPv6 adresách, kdy Android pro IPv6 provoz používá náhodně volené IPv6 adresy bez pevné vazby na MAC adresu zařízení.
-
Richard (neregistrovaný)
Aha, tak to se omlouvám, že píšu na nesprávnou adresu. Nějak jsem nabyl dojmu, že to spolu asi souvisí, obvzlášť když mně sem Google na můj dotaz ohledně MAC adres odkázal ...
Jinak mně to taky dost překvapilo, a navíc jeden přístroj to nedělá a dva další ano ... To číslo MAC adresy se samozřejmě opravdu zobrazuje tam, jak píšete, ale stačí vypnout a zapnout telefon nebo i jen samotnou Wifi, a už se změní. Tak jsem z toho trochu "na prášky" ...
Ale i tak děkuji za odpověď.
S pozdravem
R. Vyškovský.
