Jaderné noviny – 4. 10. 2012: IPv6 NAT a co dále bude v Linuxu 3.7

22. 10. 2012 | Luboš Doležel

Články - Jaderné noviny – 4. 10. 2012: IPv6 NAT a co dále bude v Linuxu 3.7  

Aktuální verze jádra: 3.6. Citáty týdne: Kees Cook, Rusty Russell, David Miller, Jon Masters. Vytvořena pracovní skupina linuxové bezpečnosti. Standardizace virtio. Zpochybnění omezení odkazů. Začleňovací okno verze 3.7, část první.

Obsah

• Aktuální verze jádra: 3.6
• Citáty týdne: Kees Cook, Rusty Russell, David Miller, Jon Masters
• Vytvořena pracovní skupina linuxové bezpečnosti
• Standardizace virtio
• Zpochybnění omezení odkazů
• Začleňovací okno verze 3.7, část první

Aktuální verze jádra: 3.6

Jádro verze 3.6 vyšlo 30. září. Do oznámení Linus napsal:

Když jsem minulý týden oznamoval -rc7, tak jsem řekl, že možná budu muset udělat -rc8, alepak uběhl týden a situace byla klidná a po pravdě jsem neviděl žádný velký důvod dělat další rc. Proto tu je 3.6 final.

Mezi hlavní novinky patří malé fronty TCP, klientská strana TCP fast open (serverová strana míří do 3.7), skupiny IOMMU, funkce btrfs send/receive, mechanismus pro virtualizaci zařízení VFIO a ještě více. Pro podrobnosti navštivte KernelNewbies.

Stabilní aktualizace: verze 3.5.5, 3.4.12 a 3.0.44 vyšly 2. října; každá z nich obsahuje více neobvyklé množství důležitých oprav.

Citáty týdne: Kees Cook, Rusty Russell, David Miller, Jon Masters

Není to moc pokročilý regulární výraz, ale i tak mi toto na linuxovém jádře přijde lehce alarmující:

    $ git log --no-merges v3.5..v3.6 | \
	  egrep -i '(integer|counter|buffer|stack|fix) (over|under)flow' | \
	  wc -l
    31

Kolik z nich mělo dopad ne bezepečnost? Kolik z nich dostalo CVE?

-- Kees Cook

Zvolil jsem SHA-512, protože všichni vědí, že je 512krát bezpečnější než SHA-1.

-- Rusty Russell

Známý test case, který dělá 5 milionů náhodných přístupů do 1GB paměťové oblasti klesne s povoleným THP na mém SPARC T4-2 z 20 sekund na 0,43 sekundy.

-- drobná výkonnostní vylepšení od Davida Millera

Přidal jsem mezi své schopnosti na LinkedInu „nemít žádný život“. Podpořte mě prosím!

-- Jon Masters

Vytvořena pracovní skupina linuxové bezpečnosti

Výsledkem nedávného Linux Security Summitu bylo rozhodnutí vytvořit pracovní skupinu kolem bezpečnostních problémů v Linuxu. Tato skupina už nyní existuje; pro své diskuze bude používat stávající mailing list kernel-hardening.

Hlavní stanovou pracovní skupiny je poskytovat stálé ověřování bezpečnosti jaderných subsystémů Linuxu, aby se tak pomohlo v zabezpečování linuxového jádra a upevnění důvěry v bezpečnost linuxového ekosystému.

Toto může zahrnovat témata jako tvorba nástrojů, které pomohou při zabezpečování, ověřování a testování kritických subsystémů, zda se v nich neobjevila bezpečnostní chyba, bezpečnostní vylepšení sestavovacích nástrojů a poskytování poradenství v údržbě bezpečnosti subsystémů.

Skupina má v plánu diskutovat o široké škále přístupů včetně vývoje nástrojů, statické analýzy, ověřování a snad i možnostech zpřísnění pravidel pro podepisování patchů. Zájemci se mohou připojit.

Standardizace virtio

Rusty Russell oznámil návrh na standardizaci I/O subsystému virtio.

Věřím, že standard (zvaný virtio 1.0) zvýší povědomí a nasazování v oblastech mimo obvyklý trh Linuxu/KVM. K tomu už částečně dochází, ale toto je nejjistější cesta, jak tomu pomoci. Není to ale ta nejsnazší, ačkoliv věřím, že slušný I/O standard je „Dobrou věcí“ pro všechny.

V plánu je založení pracovní skupiny OASIS, která by pomohla s vývojem (a standardizací) verze 1.0 specifikace virtio. Zajímají jej připomínky, ale v době psaní tohoto textu jich mnoho nebylo.

Zpochybnění omezení odkazů

Jednou z hlavních změn ve verzi 3.6 byl dlouho očekávaný nástup bezpečnostních omezení, která mění zpracovávání pevných a symbolických odkazů v adresářích, kam mohou všichni zapisovat. Jedním z důvodů, proč tato změna trvala tak dlouho, byly obavy, že úpravy rozbijí programy a skripty na uživatelských systémech. Nakonec se podařilo dokázat, že to problémy způsobí leda malwaru, a funkce byla začleněna.

Nyní se objevila jediná stížnost na linux-kernel, která způsobila, že vývojáři začali krok zpochybňovat – nebo přinejmenším to, jestli by funkce měla být standardně zapnutá. Linus má obavy, že by toto hlášení mohla následovat další podobná:

Mám ale obavy, že se toho vynoří víc. A až to nastane, nebudeme moci dále mít ve výchozím nastavení něco, co lidem rozbíjí jejich staré skripty, a budeme se muset spoléhat na distribuce (a uživatele), že to explicitně zapnou.

Kompatibilita je prostě až moc důležitá.

Ostatní vývojáři požadovali, aby k této změně došlo už ve stabilní aktualizaci 3.6.1. Ne všichni se na tom ale shodnou; autor patche Kees Cook říká, že výhody převažují nad obtížemi. Jaderná komunita je ale zavázaná nerozbíjet věci, které dříve fungovaly; pokud se ukáže, že způsobuje problémy více lidem, tak bude v blízké budoucnosti asi stažena.

Začleňovací okno verze 3.7, část první

Pouhých 72 dnů od začátku vývojového cyklu verze 3.6 započal tento proces nanovo otevřením začleňovacího okna verze 3.7. V době psaní tohoto textu bylo do hlavní řady přetaženo nějakých 5540 neslučovacích sad změn a další jsou na cestě. Mezi nejzajímavější změny viditelné uživatelům patří:

• Byl začleněn patch arm64 přidávající podporu pro 64bitovou architekturu ARM „AARCH64“.
• Nástroj perf kvm získal příkaz stat pro analýzu dat o událostech.
• Nový nástroj perf trace má fungovat podobně jako strace, ale má schopnost ukazovat i události mimo samotná systémová volání. Tento nástroj je stále ve vývoji; v commitu se píše: Někdy se sice zasekne, ale občas i funguje!
• Aplikace na architektuře x/390 nyní mohou využívat funkci hardwarové transakční paměti System zEC12.
• Byla přidána funkce ochrany proti přístupu supervizora.
• Souborový systém CIFS má nyní úplnou podporu SMB2.1; SMB2 je stále označené jako experimentální, ale oproti stavu „rozbitý“ je to pokrok.
• Pročišťování podstromu ARM pokračuje; podarchitektura Tegra byla plně převedena na mechanismus stromu zařízení.
• Na řídících adresářích řídících skupin nyní fungují rozšířené atributy. Toto je funkce inspirovaná Systemd, která umožňuje připojování dodatečných informací k řídícím skupinám.
• Při používání nehierarchických řadičů řídících skupin s hierarchickými bude nyní vypsáno upozornění.
• Tunelovací protokol GRE je nyní podporován na IPv6. Navíc je na IPv6 dostupné Network address translation (NAT).
• Byla začleněna serverová strana podpory vylepšení protokolu TCP fast open.
• Jádro nyní podporuje tunelovací protokol VXLAN. Více najdete v dokumentaci.
• Byla začleněna funkce posuzování integrity IMA.
• Do jádra se dostala řada změn vylepšující podporu zařízení Trusted Platform Module (TPM).

Mezi změny viditelné vývojářům jádra patří:

• Regulační subsystém nyní umí „režim bypass“, kde je vstup připojen přímo na výstup.
• Ošetřování ochranných lhůt v RCU bylo přesunuto do sady jaderných vláken, což umožňuje lepší preempci a snižuje spotřebu energie.
• Přibyla nová schopnost „parkování“ jaderných vláken. Primárním účelem je poskytnout jednoduchý mechanismus pro odklizení vláken při zpracovávání hotplug událostí CPU.
• Nový příznak časovače TIMER_IRQSAFE způsobuje spuštění funkce časovače s vypnutými přerušeními. Je to určeno k bezpečnému čekání (a rušení) časovačů z obsluhy přerušení.
• Přibyl nový framework senzorů pro zařízení HID; registruje multifunkční zařízení pro každý hub senzorů a prochází senzory k němu připojené. Více v dokumentaci.
• Bylo začleněno API pro cachování firmwaru.
• Soubor feature-removal.txt byl odstraněn.
• Byla začleněna počáteční podpora multiplatformích jader pro ARM. Jde o důležitý krok k „jedinému zImage“, který poběží na široké škále systémů ARM.
• Byl začleněn patch ne-reentrantních pracovních front.
• Práce na konverzi pro uživatelské jmenné prostory pokračují, takže nové typy kuid_t a kgid_t se objevují v čím dál větším množství jaderných subsystémů.

Začleňovací okno verze 3.7 bude otevřené asi až do 14. října. Linus ale varoval, že mezitím bude cestovat, protože bude na Korejském linuxovém fóru. Pokud mu do práce na začleňování přijde cestování, tak toto okno může být prodlouženo.

Diskuse k tomuto článku

[Jiří J.]

Jen doplním, že ten IPv6 NAT je podle všeho "jen" 1:1, díky bohu.

[Max]

Zatím ...
Zdar Max

[luky]

Co Vam tak vadi ma maskarade? Je to super vec, kdyz se nechcete nastavovat s routovanim a firewallem.

[Raduz]

Hlavně to, že si lidé myslí že se díky maškarádě nemusí nastavovat s routováním a firewallem...

[Dreit]

+1

[bigBRAMBOR]

no parkrat uz mi maskarada zachranila zivot, setkal jsem se uz s promyslovým bazmekem který nemel default GW, a neslo ani pridavat routy, proste akorat umel komunikovat se svyma pointama na likalni siti, pristup z venku byl mozny pouze diky maskarade. Ale to nic nemeni ze to co jsi psal je pravda.

[cynic_asshole]

Slyšel jsi už o ARP proxy?

[Atom321]

V čem je ARP proxy (pro tento účel) lepší než NAT?

[pavlix]

Mimochodem, všem doporučuju, pokud to jde, dávat přednost bridgování před extrémními hacky jako ARP proxy.

[Michal]

Vsem doporucuju, pokud to jde, pouzivat routovani misto NATu, ARP proxy, atd. Bohuzel ne vzdycky to jde.

Napr moje VMs ve VirtualBoxu bez NATu nemuzou mit IPv6. Routovat v6 subnet na muj laptop muzu leda doma, ale ne nikde jinde nad siti nemam takovou kontrolu. Navic bych je musel vzdycky precislovavat (RA je prima ale ne na zmenu IP x-krat za den). Bridgovat nemuzu protoze moje WiFi karta nezvlada vic nez jednu lokalni MAC adresu. Atd. NAT tohle vsechno resi.

[SPM]

Blbá wifi karta, moje bridguje v pohodě :) Co se týče přečíslování, tak jsem virtuálům strkal dvě síťovky. Jedna bridgnutá, kde se adresa mění a je na ní internet a pak interní se statickou adresou, kterou znám a můžu na ní z "hypervisoru" lézt.

[Sten]

NAT tohle sice řeší, ale řeší to blbě. V případě takového hardware je lepší ARP proxy. Ostateně, stejně jedu na OpenVPN.

[pavlix]

Bridgovat nemuzu protoze moje WiFi karta nezvlada vic nez jednu lokalni MAC adresu.

Maškarádu jako workaround pro vskutku idiotský návrh bezdrátových standardů uznávám. A to jak na L3, tak na L2.

Nicméně pro větší flexibilitu bych se i v tomto případě držel nerovnice:

Routing > Bridging > Proxy ARP > NAT

První nerovnost je spíše kvůli pořádku, druhá je pro mě dělící čára mezi konvenčním řešením a černou magií, třetí už je dělící čára, kde ztrácíme funcionalitu.

NAT tohle vsechno resi.

Naivní představa.

Nicméně, ani tvůj případ není jednoznačný. Já vždycky řeším problémy podle skutečné situace. A pokud si nosím hromadu testovacích virtuálů do sítí, nad kterými nemám kontrolu, tak pro mě třeba IP maškaráda nepřipadá v úvahu, protože to ty virtuály nemusím vůbec mít. Mým preferovaným řešením na bázi routingu je v tomto případě IPv6 tunel do jedné nebo více spolehlivých sítí, které mi poskytují prefix.

[pavlix]

pristup z venku byl mozny pouze diky maskarade

Tohle asi nebude typický use case pro IP maškarádu. A řekl bych, že když už dokážeš nasměrovat traffic, tak klidně můžeš použít jednoduchý source NAT a exponovat služby toho bazmeku pomocí jedné neobsazené IP.

Sice nemám po ruce relevantní zdroj a článek ho neodkazuje, nicméně pokud to správně chápu, tak právě 1:1 source NAT budeš mít k dispozici, ale maškarádu v tuto chvíli ne. Vývojáři tedy řeší přesně tento typ černé magie.

[Luboš Doležel (Doli)]

Dohledal jsem toto, ale nevím, jestli to je přesně ono.

[pavlix]

Díky. SNPT a DNPT. Takže to ani přesně nemapuje na SNAT a DNAT. Zdá se mi to, nebo to nepoužívá connection tracking? Tedy křišťálově čistý bezstavový překlad, pokud jsem něco nepochopil špatně. Co by mě pak ale zajímalo, je zda musím pro komunikaci z mapovaného prefixu přidávat obě dvě pravidla.

[Jiří J.]

No conntrack to podle mě používá, minimálně pro REDIRECT:

+       ct = nf_ct_get(skb, &ctinfo);
+       NF_CT_ASSERT(ct && (ctinfo == IP_CT_NEW || ctinfo == IP_CT_RELATED ||
+                           ctinfo == IP_CT_RELATED_REPLY));
+
+       if (ipv6_dev_get_saddr(dev_net(par->out), par->out,
+                              &ipv6_hdr(skb)->daddr, 0, &src) < 0)
+               return NF_DROP;
+
+       nfct_nat(ct)->masq_index = par->out->ifindex;
+
+       newrange.flags          = range->flags | NF_NAT_RANGE_MAP_IPS;
+       newrange.min_addr.in6   = src;
+       newrange.max_addr.in6   = src;
+       newrange.min_proto      = range->min_proto;
+       newrange.max_proto      = range->max_proto;
+
+       return nf_nat_setup_info(ct, &newrange, NF_NAT_MANIP_SRC);

Aby také ne, když to přidává celou "nat" tabulku.

Viz také http://lwn.net/Articles/514087/.

[pavlix]

Tenhle výcuc bude asi z jiného patche, než odkázal Doli, že?

[Jiří J.]

Ano, 8a91bb0c304b0853f8c59b1b48c7822c52362cba je zastřešující commit celé té série, mnou postnutý kousek je z "netfilter: ip6tables: add MASQUERADE target".

To ale nic neměni na tom, že REDIRECT je v podstatě přesně (conntrack-enabled) DNAT na IP adresu interface, na který přišel packet. Alespoň tomu tak je v (ipv4) iptables.

Úplně bezstavový NAT, bez jakékoli interakce s conntrackem, čistě přepis adresy na specifikovanou hodnotu, je možné realizovat přes RAWNAT, který je už nějakou nekrátkou dobu v xtables-addons, oficiálně podporován Janem Engelhardtem.

[pavlix]

Hezké.

[luky]

Muzete mi popsat nevyhody, jake podle vas ma maskarada napriklad pro instalaci Windows stanic pripadne update ruznych HW bazmeku? A jake nastaveni firewallu a routovani je podle vas nutne?

[pavlix]

Firewall se používá k ochraně sítě proti přístupu zvenčí (případně i obecněji). Použití maškarády žádné bezpečností záruky neposkytuje (pokud není doplněno firewallem). Maškaráda z principu zabezpečení sítě snižuje (zpřístupňuje služby).

Ne každá síť je triviální domácí síť připojená na jednu krabičku, která to zanatuje. Nelze zrušit routing jen kvůli tomu, že máme maškarádu.

[Raduz]

No, nejdřív bych se zeptal já jak s tou instalací Win stanic a updated různých HW bazmeků maškaráda přesně souvisí. Jako jasně, chápu že člověk má lepší pocit, když si řekne "Tak, tady je moje uzavřená LAN plná oveček s privátními adresami, a vlci jsou až za tímhle NAT serverem.", ale už je chyba si myslet "...takže je to v pohodě, vlci mají smůlu, protože o ovečkách nevědí, a vrátka si sami neotevřou." Jenže vlci jsou sakra rafinovaní, a převléknou se ti za ovečku ani nevíš jak. A pak máš najednou ohrádku plnou vlků...

Dost bylo metafor. To na co jsi se ptal s maškarádou nijak nesouvisí. Všechno se to dá udělat bezpečně i s veřejnými adresami, jen to samozřejmě dá nějakou práci. Pokud se domníváš, že díky NATu se té práci vyhneš, mýlíš se, a navíc se necháváš ukolébat falešným pocitem bezpečí. Není firewall, není bezpečnost. A jestli přes běžný default GW routuješ privátní nebo veřejné adresy je co se náročnosti nastavení celkem jedno.

[j]

Konfigurace firewallu s NATem je o rad slozitejsi nez bez nej => poskytuje mnohem vic prostoru pro potencielni chybu. Navic sebou NAT nese i dalsi bezpecnostni rizika - napr si musi pamatovat navazana spojeni, coz si router pamatovat nemusi. Pokud hacknu takovou krabku, mam okamzitej prehled, nemusim ani nic nikde snifovat.

[Max]

Ještě bych přidal to, že NAT více zatěžuje hw.
Zdar Max

[pavlix]

Konfigurace firewallu s NATem je o rad slozitejsi nez bez nej => poskytuje mnohem vic prostoru pro potencielni chybu.

To je pravda, naštěstí netfilter tohle docela spokojeně obchází.

Navic sebou NAT nese i dalsi bezpecnostni rizika - napr si musi pamatovat navazana spojeni, coz si router pamatovat nemusi.

To by se ti projevilo jen v extrémním prostředí, jinak je IMO riziko ekvivalentní a v případě firewallu na stejné krabce spíše totožné (tedy až na falešný pocit bezpečí).

[darkenik]

tak ak nemame nat, musime nakonfigurovat FW, s najvacsou pravdepodobnostou stavovy firewall, takze tabulka spojeni tam bude tak ci tak.

[Sten]

I když máte NAT, musíte (měl byste) nastavit firewall

[Jezus]

+1 Maskarada je neskutecne zlo

[pavlix]

Náhodou. Díky tomu, že NATu obecně a různým kombinacím port redirectů, maškarád, bridgování, icmp redirectů apod nikdo pořádně nerozumí, tak jsem měl jako OSVČ aspoň vždycky nějaký ten výdělek :).

[pavlix]

Jen doplním, že ten IPv6 NAT je podle všeho "jen" 1:1, díky bohu.

Snažím se tuhle oblast sledovat a taky mě úplně netěší, že autoři plácnou do článku nic neříkající informaci, že se začleňuje nějaký překlad adres. To by rovnou mohli napsat, že kernel bude mít „novou síťovou fíčuru“ a informační hodnotu by to mělo skoro stejnou.

[KOLEGA]

Vždycky přemýšlím, kdo je tak ochotný a sesmolí pro nás takovéhle slohy... Každopádně díky moc

[progdan]

Jonathan Corbert (a Lubos samozrejme :) )