Jaderné noviny – 4. 2. 2015: Linux jako single-user systém

4. 5. 2015 | Redakce | Jaderné noviny | 4431×

Stav vydání jádra. Citát týdne. Linux jako systém jediného uživatele

Stav vydání jádra

Aktuální vývojové jádro je 3.19-rc7, vydané 1. února. "Všechno se zdá být v pořádku, takže se pravděpodobně jedná o poslední rc, pokud se neobjeví něco neočekávaného. Což znamená, že bych chtěl, aby více lidí zkoušelo pro kontrolu bootovat a testovat tohle bejby."

Stabilní aktualizace: 3.18.5, 3.14.31 a 3.10.67 byly vydány 29. ledna.

V revidování jsou aktualizace 3.18.6, 3.14.32 a 3.10.68. Můžeme je očekávat 5. února nebo později.

Citáty týdne

Připojíte-li Rasberry Pi k modernímu velkému disku, je velká šance, že chytřejší zařízení na konci kabelu je ten disk.

- Alan Cox (Díky Stevenu Rostedtovi a Borislavu Petkovovi).

Vůbec jsme nemuseli IPSEC implementovat, protože kvůli uživatelským aplikacím na privátních sítích jej využívá jen velmi úzký okruh lidí.

- David Miller

Linux jako single-user systém

V dávné a temné minulosti (2001) zveřejnil kdosi pod jménem "imel" patch, který v kernelu eliminoval uživatele, takže vše fungovalo pod rootem. Není překvapením, že tehdy nebral tenhle patch nikdo moc vážně. Verze podobného patche se však po 14 letech znovu objevila a tentokrát vyvolala mnohem živější diskuzi.

Patch, o kterém je řeč, pochází od Iulie Mandy. Vytváří v kernelu nabídku, která odstraňuje systém více uživatelů. Při správné konfiguraci spouští kernel všechny procesy s ID uživatele a skupiny nastavenými na 0 a všemi příznaky schopností. Tato možnost také ruší podporu pro dlouhý seznam systémových volání, které se zabývají ID a schopnostmi uživatelů a skupin.

Jak už to bývá v případě patchů, které vzbuzují pozornost, je tento poháněn úsilím ke zmenšení jádra, které se snaží nasadit kernel do systémů s malou pamětí. Na takových systémech poběží pravděpodobně jediná dedikovaná aplikace, pravděpodobně inicializační a ty mají pro množství funkcí, které kernel nabízí, velmi malé využití - četně například provozu více uživatelů. Nastavením této konfigurace se dá ušetřit trochu paměti (cca 25 KB), což usnadňuje instalaci současného kernelu na malá SoC.

Vzhledem k podstatě patche by nebylo divné vidět dlouhý seznam jeho odpůrců. Ve skutečnosti se množina odpůrců skládá hlavně z Caseyho Schauflera, který řekl:

Autoritativní LSM hooky byly hlasitě zamítnuty kolem roku 1999. Jedním z důvodů pro jejich zamítnutí bylo, že je bylo možné využít ke stejnému účelu, jaký nabízí tento patch, což je odstranění základních zásad zabezpečení Linuxu. Pokud se postoj (uživatelů) změnil natolik, že odstranění "tradičního" zabezpečení je bráno jako přijatelné, navrhuji, abychom místo patche znovu zavedli možnost autoritativního LSM hookování.

"Autoritativní LSM hooky" jsou zabezpečovací moduly Linuxu, které umožňují zvyšovat privilegia běžícím procesům. Hodně se o nich diskutovalo v roce 2001, kdy byl mechanismus bezpečnostních modulů vyvíjen. Autoritativní hooky nakonec neprošly; byly vnímány jako významné bezpečnostní riziko samy o sobě. Toto rozhodnutí tehdy kritizoval Casey Schaufler, který jej viděl jako zbavování se důležitých funkcí k usnadnění slučování bezpečnostních modulů do jádra.

O mnoho let později na to Casey zjevně nezapomněl. Údajně by rád viděl možnost single-user (jediného uživatele), pokud by k jejímu zavedení mělo dojít, realizovanou jako bezpečnostní modul za pomoci autoritativních hooků. Vývojáři pracující na zmenšování nejsou touto myšlenkou nadšeni; na druhou stranu by znovuzavedení autoritativních hooků znamenalo oživení staré (a vyřešené) diskuze a dostat se k možná horšímu řešení problému, který chtějí vyřešit. Což znamená, že tento patch se v tímto směrem vyvjíjet pravděpodobně nebude.

Kromě toho vznesl Casey námitku, která přišla už dříve s ohledem na zmenšovací patch. "Otevíráte dveře k možnosti vytvořit Linux, který se nechová jako Linux." Mnoho podobných patchů z této oblasti bude mít podobný efekt. Jsou vyvíjeny s ohledem na odstraňování funkcí, které nejsou pro dané konkrétní využití nutné. Pokud by jádro mělo být využitelné na malých systémech, muselo by být dostatečně flexibilní, aby se na těchto systémech "nechovalo jako Linux."

Tohle je jedna z možností jak s tímto problémem nakládat. Josh Triplett odpověděl, že možnost nakonfigurovat funkce z jádra je možné již dlouho, a že patche pro single-user systém nejsou nic nového.

Takže co má znamenat "Linux, který se nechová jako Linux"? Linux je vše, co obsahuje linux.git; je dnes mnohem schopnější než dřív, což neznamená jen *přidávání* funkcí. Alternativou k menšímu Linuxu není větší Linux, ale nelinuxový vestavěný operační systém, který se *nechová* jako Linux, protože se *nejedná o Linux*.

Celkově vzato dojde na několik otázek: Dokážou vývojáři zmenšující Linux prezentovat ty změny tak, aby je širší vývojářská komunita mohla akceptovat a je tato komunita ochotná tolerovat patche, které umožňují zásadní změny fungování jádra? Nejedná se o novou diskuzi, objevila se například na Kernel Summitu v roce 2014. Nebude to ten typ diskuze, u které je možné dojít k rychlým závěrům. Jenomže pokud Linux nebude schopen běžet na malých systémech, bude vytlačen jiným operačním systémem, který v takových prostředích pracuje dobře.

       

Komentáře

[pavlix]

Nedávno jsem na něčí žádost přidával userspace ipsec i do fedořího balíčku strongswanu, nakonec se aktivuje instalací podbalíčku. Taky mě to mrzí, osobně mi přijde to, jak funguje ipsec v kernelu geniální, ale lidi jsou podle všeho prostě zvyklí na openvpn-style práci, kdy se namísto bezpečnostní politiky používá směrovací tabulka a virtuální rozhraní.

[Michal]

Co je na tom genialniho? Bez interfacu se neda poradne videt co se deje v IPsec tunelu (tcpdump), nedaji se automaticky pridavat routy z IPsecu do OSPF, nedaji se jednoduse nakonfigurovat iptables stejnym zpusobem jako pro vsechny ostatni rozhrani, atd. Proste v beznem provozu megavopruz maximalni. Sice z teoretickeho hlediska je to mozna navrzene ciste a pokrokove, ale z pohledu cloveka co se o takovy router ma starat je to fakt voser.

Byvaly doby kdyz kazdy ipsec tunel byl normalni interface - ale to bylo mozna jeste ve 2.4.x. Kazdopadne hodne hodne davno...

[trekker.dk]

Jo, tak u toho jsem taky s IPsec skončil dřív, než jsem začal. Přiznám se, že jsem trochu nevěřil vlastním očím - všechno ostatní (bond, virtuální tap rozhraní, bridge, gre tunel...) se v kernelu chová jako interface a taky se s tím tak dá pracovat, jenom tady se někdo rozhodl, že vymyslí kolo. Neúspěch jaderného IPsec bych tak možná přičítal víc praštěné (admin-unfriendly) implementaci, než konkurenci ze strany aplikací v uživatelském prostoru.

[Ilmarinen]

Nevím, no, nám ke štěstí s IPSec stačily loopback rozhraní a všechno řešit přes ně.

[Ondrej Santiago Zajicek]

Tady je trochu terminologicke zmateni - IPSec nabizi tunnel mode, jenze tunnel mode nezajistuje (a ani nema nezajistovat) to, co si lide obvykle predstavuji pod pojmem tunel. Proto se taky netvari jako virtualni rozhrani. V soucasnosti je ale nejspis daleko casteji treba skutecny tunel, zatimco use case pro IPSec tunnel mode je pomerne okrajovy. V takovem pripade je bezny postup provozovat IPIP nebo GRE tunel chraneny pomoci IPSec transport mode.

[pavlix]

V takovem pripade je bezny postup provozovat IPIP nebo GRE tunel chraneny pomoci IPSec transport mode.

Je k tomu ovšem nějaký technický důvod? Proč bych měl používat další zapouzdření, jestliže můžu po drátě posílat pakety tak jak jsou?

[Honza Jaroš]

Napadá mě třeba to zmiňované OSPF, nějak se mi nepodařilo nalézt smysluplné řešení, které by fungovalo s IPSec tunely. Ale možná jsem jen něco přehlédl...?

[pavlix]

Podle mě jsi přehlédl smysl otázky. Tázal jsem se na technický důvod, pro použití další hlavičky (zapouzdření) navíc ke klasickému IP-ESP-IP, popřípadě IP-UDP-ESP-IP, tedy například IP-ESP-GRE-IP. Nejsem si vědom toho, že by pro použití OSPF byla GRE nebo podobná hlavička přímo potřeba.

[Honza Jaroš]

Ondřej Zajíček píše, že v soucasnosti je ale nejspis daleko casteji treba skutecny tunel, zatimco use case pro IPSec tunnel mode je pomerne okrajovy. Neměla by tedy otázka spíše znít "proč je use case pro IPSec tunel poměrně okrajový"?

To zapouzdření má podle mě jediný důvod: IPSec tunely se nechovají jako klasické tunely s extra rozhraním a standardním routováním a tudíž tam, kde je potřeba klasický tunel (proto píšu o OSPF, protože pokud vím, to nad IPSec tunelem dost dobře použít nejde), se buď zapouzdřuje, nebo se použije úplně jiné řešení typu OpenVPN. Jinak to samozřejmě podle mě zapouzdření smysl nemá a nemám pocit, že by Ondřej Zajíček tvrdil něco jiného.

[pavlix]

To zapouzdření má podle mě jediný důvod: IPSec tunely se nechovají jako klasické tunely s extra rozhraním a standardním routováním

Ptal jsem se na technický důvod, tohle je omezení implementace a v takovém případě se bavíme o typickém příkladu rovnáku na vohejbák, v tomhle případě ovšem rovnáku na úrovni komunikace (která by měla být standardizovaná a neměnná) na vohejbák v implementaci (která by se naopak měla přizpůsobovat definované komunikaci).

proto píšu o OSPF, protože pokud vím, to nad IPSec tunelem dost dobře použít nejde

To ovšem není vůbec pravda, jak dokládají i implementace v userspace.

[Honza Jaroš]

Ptal jsem se na technický důvod, tohle je omezení implementace a v takovém případě se bavíme o typickém příkladu rovnáku na vohejbák, v tomhle případě ovšem rovnáku na úrovni komunikace (která by měla být standardizovaná a neměnná) na vohejbák v implementaci (která by se naopak měla přizpůsobovat definované komunikaci).

...

To ovšem není vůbec pravda, jak dokládají i implementace v userspace.

Tak to pardon, já měl za to, že se tady celou dobu hovoří o IPSec takovém, jak je implementované v linuxovém jádře.

[pavlix]

Ono je to téma asi trochu zamlžené.

[Ondrej Santiago Zajicek]

Ptal jsem se na technický důvod, tohle je omezení implementace a v takovém případě se bavíme o typickém příkladu rovnáku na vohejbák,

Problem je v tom, ze RFC 4301 definujici IPSec nestandardizuje jen samotny sitovy protokol (wire format), ale take (do urcite miry) chovani koncovych bodu. A soucasti toho standardizovaneho chovani je i SPD (Security Policy Database), tedy to, co je v Linuxu reprezentovano jako XFRM databaze. Implementace, ktera by implementovala IPSec tunnel mode pomoci virtualnich interface bez interakce s SPD pro vnitrni data, je tedy IMHO nekonformni vuci RFC 4301.

Navic bych nerekl, ze pouziti IPIP tunelu a IPSec transport mode je rovnak na ohybak. Naopak je to primocare a ciste reseni, kdy clovek slozi dva nezavisle nastroje (tunelovaci protokol a IPSec pro zajisteni privacy), kazdy nabizejici polovinu potrebne funkcionality, aby dosahl celku. Oproti tomu IPSec tunnel mode je splacanina techto koncepcne nezavislych veci do jednoho neprehledneho gulase.

[pavlix]

Implementace, ktera by implementovala IPSec tunnel mode pomoci virtualnich interface bez interakce s SPD pro vnitrni data, je tedy IMHO nekonformni vuci RFC 4301.

Možná formálně nekonformní, ale rozhodně do značné míry interoperabilní, což je mnohem důležitější, nehledě na to, že v případě podopory obou dvou modelů chování v systému by se jednalo spíše o rozšíření než o porušení.

Navic bych nerekl, ze pouziti IPIP tunelu a IPSec transport mode je rovnak na ohybak.

To je ovšem velké nepochopení, vyjadřoval jsem se k přidání GRE hlavičce do paketů jako metodě řešení omezení na straně operačních systémů, nikoli k použití IPIP přes transport mode nebo k reinterpretaci tunnel mode jako IPIP přes transport mode.

Oproti tomu IPSec tunnel mode je splacanina techto koncepcne nezavislych veci do jednoho neprehledneho gulase.

To nerozporuju.

[Ondrej Santiago Zajicek]

IMHO tam zadne dodatecne zapouzdreni byt nemusi - pokud se pouzije IPIP tunel chraneny IPSec transport mode, tak to take vypada jako IP-ESP-IP (dokonce udajne je snad mozne mit na jednom konci IPSec tunnel mode a na druhem konci IPIP tunel chraneny IPSec transport mode a mit to interopretabilni - wire format je stejny, lisi se pouze interpretace a chovani koncovych bodu, v jednom pripade XFRM policy, v druhem virtualni rozhrani a routovaci tabulka).

Pouziti GRE tunelu namisto IPIP tunelu tam malou hlavicku prida (je to tedy IP-ESP-GRE-IP), ta jednak umozni identifikovat prenaseny protokol, takze tunel muze slouzit pro vice protokolu zaroven (napr. IPv4 a IPv6 v jednom IPv4 tunelu) a jednak umoznuje odlisit vice paralelnich tunelu mezi stejnymi body (pokud je to k necemu treba). Kazdopadne puvodni argument funguje stejne dobre i pro obycejne IPIP tunely.

Existuje RFC 3884 pojednavajici o nasazeni IPIP tunelu chranenych IPSec transport mode.

[pavlix]

IMHO tam zadne dodatecne zapouzdreni byt nemusi - pokud se pouzije IPIP tunel chraneny IPSec transport mode, tak to take vypada jako IP-ESP-IP (dokonce udajne je snad mozne mit na jednom konci IPSec tunnel mode a na druhem konci IPIP tunel chraneny IPSec transport mode a mit to interopretabilni

To zní dost zajímavě a šlo by to docela dobře řešit na úrovni konfigurační direktivy v software na tom kterém konci.

Pouziti GRE tunelu namisto IPIP tunelu tam malou hlavicku prida (je to tedy IP-ESP-GRE-IP), ta jednak umozni identifikovat prenaseny protokol, takze tunel muze slouzit pro vice protokolu zaroven (napr. IPv4 a IPv6 v jednom IPv4 tunelu)

Tak zrovna IPv4 a IPv6 není problém zároveň provozovat i bez GRE, ne?

a jednak umoznuje odlisit vice paralelnich tunelu mezi stejnymi body

Pokud je něco takového potřeba.

Existuje RFC 3884 pojednavajici o nasazeni IPIP tunelu chranenych IPSec transport mode.

To se podívám, díky.

[Ondrej Santiago Zajicek]

To zní dost zajímavě a šlo by to docela dobře řešit na úrovni konfigurační direktivy v software na tom kterém konci.

IMHO nejcistci zpusob, jak to nastavit, je nastavit nezavisle IPIP tunel a pro nej IPsec transport mode.

Tak zrovna IPv4 a IPv6 není problém zároveň provozovat i bez GRE, ne?

Klasicky by na to byly dva nezavisle interfacy (ipip tunel a sit tunel). Tusim, ze nedavno v Linuxu implementovali i nejaky hybridni rezim umoznujici zaroven ip4-in-ip4 a ip6-in-ip4 na jednom iface, ale man ip-tunnel ho nezminuje. Oproti tomu GRE tunel umoznuje predavat libovolny (ethernet-ready) sitovy protokol, jako by slo o skutecnou L2 linku. Hadam, ze skrz IPIP tunel bych nerozbehl IS-IS routovaci protokol, ktery na rozdil od OSPF bezi primo na linkove vrstve.

Pokud je něco takového potřeba.

Napr. v pripade, kdy se prenasi nekolik nezavislych VPN mezi dvema hranicnimi body, pak bude kazda ve vlastnim tunelu.

[Michal Kubeček]

Oproti tomu GRE tunel umoznuje predavat libovolny (ethernet-ready) sitovy protokol, jako by slo o skutecnou L2 linku. Hadam, ze skrz IPIP tunel bych nerozbehl IS-IS routovaci protokol, ktery na rozdil od OSPF bezi primo na linkove vrstve.

Kdybych měl takové potřeby, tak už bych asi šel rovnou do vxlan.

[pavlix]

Kdybych měl takové potřeby, tak už bych asi šel rovnou do vxlan.

Takhle bez zdůvodnění to působí jako mlácení prázdné slámy, nějaké srovnání?

[Michal Kubeček]

Pokud už bych chtěl přes ten tunel posílat (nejméně) tři různé protokoly sedící přímo nad ethernetem, tak už bych asi dal přednost propojení přímo na L2 úrovni. Jako bonus by pak fungovaly i multicasty a broadcasty, což by třeba ten IS-IS mohl využívat.

[pavlix]

Co přesně z toho GRE neposkytuje?

[Michal Kubeček]

Přes GRE můžu sice poslat paket jakéhokoli protokolu, který lze poslat přes ethernet, ale posílám právě jen tu část, která je nad ethernetem, takže ten routing musím řešit pro každý protokol zvlášť. U vxlan se tuneluje přímo ethernet, takže stačí definovat, jak se má chovat ten, a zbytek bude fungovat automaticky.

Ale každému to tak samozřejmě vyhovovat nemusí.

[pavlix]

Technickou stránku, tedy zda se posílají celé ethernetové rámce nebo ne, chápu. Ptal jsem se ovšem na praktické důsledky a ty skutečně z tvého komentáře nevyčtu. Jediné, kde se toho dotýkáš, je „takže ten routing musím řešit pro každý protokol zvlášť“, ale to se mi bohužel nepodařilo dešifrovat.

[Michal Kubeček]

V tom případě mi není jasné, jak konkrétně by sis představoval "praktické důsledky".

„takže ten routing musím řešit pro každý protokol zvlášť“, ale to se mi bohužel nepodařilo dešifrovat.

Při použití GRE budu muset nějak říct, že určité adresy jsou dostupné přes ten tunel. To znamená nastavit IPv4 adresy a routu(-y), IPv6 adresy a routu(-y) a něco obdobného ještě pro ten IS-IS. Při svém řešení nastavím vxlan (není o moc složitější než GRE), IPsec pro jeho zabezpečení (stejné) a pak už bude všechno fungovat, jako kdybych byl na jednom segmentu (pokud to vysloveně nebudu chtít jinak). Mně to přijde praktičtější a přehlednější.

[pavlix]

V tom případě mi není jasné, jak konkrétně by sis představoval "praktické důsledky".

Podle toho, co o tobě říkají jiní (včetně MJ) máš znalosti a zchopnosti na rozlišení technických detailů a praktických důsledků a tudíž mi nezbývá než považovat tuto větu za provokaci.

Při použití GRE budu muset nějak říct, že určité adresy jsou dostupné přes ten tunel.

To skoro zní, jako by tomu u vxlan mělo být jinak.

Mně to přijde praktičtější a přehlednější.

Obávám se, že jsem se zatím nedozvěděl v čem.

[pavlix]

Za překlep se omlouvám.

[Michal Kubeček]

Nemám čas ani náladu na další zbytečnou přetahovanou. Napsal jsem, co si myslím, napsal jsem, proč si to myslím, a jestli ti to nestačí, tak to je holt smůla, ale rozhodně ne můj problém a moje starost.

[pavlix]

Nemám čas ani náladu na další zbytečnou přetahovanou.

Nepřetahuju se, jen jsem se na něco ptal a v reakcích jsme hledal odpovědi. To, že ani nedozvím, že nemám odpověď čekat, mě sice unavuje, ale na ábíčku jsem na tu už připravený a nedělám z toho žádnou vědu.

napsal jsem, proč si to myslím

Nenapsal.

a jestli ti to nestačí, tak to je holt smůla, ale rozhodně ne můj problém a moje starost.

Jen jsem se zeptal a následně upozornil, že jsem dostal zmatečnou reakci. Necítím se býti vinen za to, že si to bereš osobně.

[pavlix]

IMHO nejcistci zpusob, jak to nastavit, je nastavit nezavisle IPIP tunel a pro nej IPsec transport mode.

V této větě řeším to, že si dvě implementace například IKEv2 vymění informace o tom, jak má vypadat tunel a některá z nich na základě lokální konfigurace namísto tunelu v SPD vytvoří kombinaci transportu a ipip, který jsi ty navrhoval. Bavíme se tedy o úplně jiných vrstvách, jinak řečeno já o voze, ty o koze.

Klasicky by na to byly dva nezavisle interfacy (ipip tunel a sit tunel).

To rozdělení typů tunelů mi samo o sobě připadá úplně debilní. Máš jeden princip

Tusim, ze nedavno v Linuxu implementovali i nejaky hybridni rezim umoznujici zaroven ip4-in-ip4 a ip6-in-ip4 na jednom iface, ale man ip-tunnel ho nezminuje.

Ta manstránka je sto let za opicema, nevyjmenovává správně ani tunely (viz manpage megapatch, co jsem posílal v rámci větší sady a který nejspíše budu rozdělovat na menší). I když on i ten příkaz je blbě postavený vzhledem k IPv4 a IPv6.

Oproti tomu GRE tunel umoznuje predavat libovolny (ethernet-ready) sitovy protokol, jako by slo o skutecnou L2 linku.

Jo, to by dávalo smysl.

Napr. v pripade, kdy se prenasi nekolik nezavislych VPN mezi dvema hranicnimi body, pak bude kazda ve vlastnim tunelu.

Captain Obvious, tady bych se musel asi opakovat.

[pavlix]

Mimochodem GRE tunely mi v příkazu ip tunnel nechtějí vůbec fungovat. Jen si hraju a hledám chyby, nehledám příklady funkčních příkazů. Nehledě na to, že se podle kódu snad ani nepoužívá netlink!

Na druhou strany co jsem se ptal (a teprve se chystám vyzkoušet), tak pyroute2 přes netlink by měl fungovat v pohodě.

[Jendа]

Bez interfacu se neda poradne videt co se deje v IPsec tunelu (tcpdump)

To podle mě není problém toho že tam není interface ale toho že (ty|Linux) neumí chytat pakety jinde než „na konektoru síťovky“.

nedaji se automaticky pridavat routy z IPsecu do OSPF, nedaji se jednoduse nakonfigurovat iptables stejnym zpusobem jako pro vsechny ostatni rozhrani

Počkej, jak ty používáš ipsec? Já měl za to že se používá k zabezpečení paketů mezi stroji a má být o vrstvu níž, tohle by vůbec neměl řešit.

[Michal]

Počkej, jak ty používáš ipsec?

Treba takhle - na propojeni firmy s Amazon VPC pres Virtual Private Gateway, coz je IPsec se dvema nezavislyma cestama. Na kazde strane jsou nejake adresni rozsahy, vzajemne se maji videt, Amazon je umi do tunelu exportovat pres BGP, ale jak je mam na nasi strane importovat do BGP/OSPF kdyz v Linuxu nejsou nikde videt jako vsechny ostatni routy treba z OpenVPN tunelu? Sice si je muzu zjistit pres ip xfrm policy show, ale proc takhle komplikovane kdyz vsechny ostatni routy vsech ostatnich tunelu vidim pres ip route show - proc ne ty z IPsecu?

Reseni s IPIP nebo GRE tunelem uvnitr IPsec neni moc sikovne pokud nemam pod kontrolou oba konce, coz tady nemam. Amazon to samozrehne primo nepodporuje takze bych muse zbytecne platit extra EC2 instanci jen na zakonceni tohoto tunelu, navic k tomu resit high availability (zatimco s Virtual Private Gateway to za me resi Amazon), atd. Pritom by stacilo abych tenhle tunel v Linuxu videl jako interface a k tomu par routes stejne jako treba u OpenVPN (ktery - cosi budem nalhavat - zajistuje uplne tu stejnou funkci, akorat jinym protokolem).

Takze jak rikam - linuxova implementace je zbytecny vopruz. Musim zkusit jestli mi v clanku zmineny vti tunel nejak pomuze...

[Michal Kubeček]

proc takhle komplikovane kdyz vsechny ostatni routy vsech ostatnich tunelu vidim pres ip route show - proc ne ty z IPsecu

Security policy je něco úplně jiného než routa. Routa mi říká, kam mám paket poslat, security policy jak (a jestli) má být zabezpečen, to jsou dvě nezávislé věci.

[pavlix]

U tunelového režimu to není tak úplně pravda. Security policy pak ovlivňuje i kam se paket pošle.

[Michal Kubeček]

Ale zase přes routing. Security policy sama o sobě říká jen to, jaké adresy mají být ve vnější IP hlavičce; kudy se to pošle, o tom rozhodne routing podle svých vlastních pravidel a rout. Stejně tak se dá říct, že routa v konečném důsledku ovlivní, jaká bude cílová MAC adresa, ale neoznačil bych to za její účel.

[Michal]

Takže jsme zpátky u toho že celá ta šaškárna s XFRM je asi z teoretického a softwarově inženýrského hlediska geniálně navržená, ale bohužel v praxi se to používat nedá.

Admin chce prostě IPsec tunel mezi dvěma sítěmi - ano přesně ten tunel který si pod pojmem tunel každý admin představí.

Ze zkušenosti a z diskuzí s kolegy můžu říct že většina adminů nemá z "geniálního návrhu" linuxového IPsecu ani trochu radost.

[Michal Kubeček]

…je asi z teoretického a softwarově inženýrského hlediska geniálně navržená, ale bohužel v praxi se to používat nedá.

Kdyby se používat nedala, nepoužívala by se. Ale ona se používá a jak ukazuje příklad o kterém jsem se zmiňoval, někde i hodně ve velkém.

Ze zkušenosti a z diskuzí s kolegy můžu říct že většina adminů nemá z "geniálního návrhu" linuxového IPsecu ani trochu radost.

A pak je spousta takových, se kterými jste se asi nebavil, ale kteří by neměli ani trochu radost z toho vašeho. Možná vás to překvapí, ale za design decisions v síťovém subsystému obvykle nestojí to, že by si někdo sedl a řekl si: "Tak co bych dneska vymyslel hloupého, abych tím naštval adminy?" Za sebe můžu říct, že ze začátku jsem byl taky trochu překvapený, ale jakmile jsem se s tou implementací trochu seznámil (tehdy pouze z pohledu admina), uvědomil jsem si, že je mnohem názornější a mnohem lépe odpovídá tomu, jak IPsec funguje.

[pavlix]

Za sebe můžu říct, že ze začátku jsem byl taky trochu překvapený, ale jakmile jsem se s tou implementací trochu seznámil (tehdy pouze z pohledu admina), uvědomil jsem si, že je mnohem názornější a mnohem lépe odpovídá tomu, jak IPsec funguje.

S tím souhlasím, a ještě dodávám, že je IPsec jako takový navržený hezky.

[trekker.dk]

Z originálu (David Miller ):

as a result of the userland VPN stuff our IPSEC stack is largely unused except by a very narrow group of users

Ano, toto neznamená, že se jaderná implementace ipsec nepoužívá. Ale dost zjevně z toho vyplývá, že ji používá málokdo. IMO je ten "geniální" návrh jedním z důvodů, proč tomu tak je.

[Michal Kubeček]

Nebo je zatím spíš neochota některých adminů učit se a zakonzervovanost v kleci toho, na co jsou zvyklí. Třeba netstat taky používá víc lidí než ss a ani zdaleka to neznamená, že by fungoval lépe.

[trekker.dk]

Z toho "very narrow group" by vyplývalo spíš neochota většiny adminů... a jestli většina adminů něco odmítne, tak bych to bral jako podnět k zamyšlení nad tím, jestli to bylo (s ohledem na cílovou skupinu) dobře vymyšleno

[Michal Kubeček]

Když si ten mail přečtu celý, tak to na mne působí spíš tak, že ta většina adminů, o které je řeč, nepřemýšlí o tom, jak je co navrženo, ale prostě použije nějakou hotovou spatlaninu typu vpnc.

[pavlix]

Nebo je zatím spíš neochota některých adminů učit se a zakonzervovanost v kleci toho, na co jsou zvyklí.

Jakožto (mimojiné) fedoří maintainer balíku obsahujícího příkaz ss můžu svědomitě říct, že lidé k ignorování toho příkazu měli dost dobré důvody, vedle obvyklého konzervativismu.

Třeba netstat taky používá víc lidí než ss a ani zdaleka to neznamená, že by fungoval lépe.

To sice neznamená, ale na věci to vůbec nic nemění.

[Michal Kubeček]

Jakožto (mimojiné) fedoří maintainer balíku obsahujícího příkaz ss můžu svědomitě říct, že lidé k ignorování toho příkazu měli dost dobré důvody

Tak ty by mne docela zajímaly. Rozdíl ve výkonu je propastný, poskytované informace výrazně bohatší, možnost filtrace podle adresy nebo portu rovnou při získávání dat, … Dokonce odpadá i argument zpětné kompatibility, protože nejpoužívanější přepínače jsou stejné.

Moje zkušenosti jsou takové, že zdaleka nejčastější důvod, proč uživatelé ss nepoužívají, je ten, že o něm nikdy neslyšeli. Jak se o něm dozvěděli, byly už reakce většinou pozitivní (až na obvyklou poznámku o nešťastně zvoleném názvu), na rozdíl třeba od ip.

[pavlix]

Ještě nedávno (například verze, co šla do RHEL 7.0) to neumělo ani správně selectovat podle rodiny/protokolu, ani správně zobrazit, o jaký protokol se jedná. Pokud chceš u konzervativních adminů vytlačit osvědčený nástroj, měl by ten nový aspoň pár let fungovat.

Dokonce odpadá i argument zpětné kompatibility, protože nejpoužívanější přepínače jsou stejné.

Nemám ten dojem. Volá se to o dost jinak, výstup je úplně jiný, navíc zpravidla hůře čitelný, spoustu věcí to vůbec neumí, jako třeba výběr několika rodin. Nechce se mi teď hledat seznam všech hlášených problémů, koneckonců stačí trochu sledovat Git a uvidíš, co se v posledním roce řešilo a průběžně uvidíš, co se bude řešit dál.

Jako uživatel 'ss' zásadně nepoužívám, přestože se teď starám o to, aby ho mohli používat jiní. Popravdě mi 'ip' proti tomu přijde jako zásadnější vylepšení, mnohem vyspělejší, i když stále ještě nedostatečně zdokumentované. Jako programátor dokážu spoustu věcí ocenit, ale jako uživatel vnímám celý ten balík jako nedotažený zabugovaný bordel, přičemž u 'ip' mám alespoň dobré důvody, proč ho používat, zatímco 'ss' působí spíš jako nechtěné dítko.

[Michal Kubeček]

I kdyby jedinou výhodou ss bylo to, že v (nijak hypotetické) situaci, kdy netstat trvá přes minutu, ss totéž zvládne za dvě sekundy (i bez filtru), tak by mi to jako uživateli úplně stačilo.

[pavlix]

To vše ovšem za předpokladu, že pro daného uživatele ta situace skutečně není nijak hypotetická.

[Jendа]

Tak ty by mne docela zajímaly.

Tak třeba nečitelný výstup při úplně základním použití. Příklad:

~ # netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:9966          0.0.0.0:*               LISTEN      10714/ssh       
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      10714/ssh       
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      28487/lighttpd  
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN      25898/cupsd     
tcp        0      0 127.0.0.1:9944          0.0.0.0:*               LISTEN      10714/ssh       
tcp        0      0 127.0.0.1:8088          0.0.0.0:*               LISTEN      4357/ssh        
tcp        0      0 127.0.0.1:9945          0.0.0.0:*               LISTEN      10714/ssh       
tcp        0      0 127.0.0.1:2299          0.0.0.0:*               LISTEN      4357/ssh        
tcp        0      0 127.0.0.1:2525          0.0.0.0:*               LISTEN      10714/ssh       
tcp        0      0 127.0.0.1:9955          0.0.0.0:*               LISTEN      10714/ssh       
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      10283/ssh       
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      1040/memcached  
tcp6       0      0 :::631                  :::*                    LISTEN      25898/cupsd     
tcp6       0      0 ::1:8088                :::*                    LISTEN      4357/ssh        
tcp6       0      0 ::1:2299                :::*                    LISTEN      4357/ssh        
tcp6       0      0 ::1:3306                :::*                    LISTEN      10283/ssh       
~ # ss -tlpn
State       Recv-Q Send-Q                                              Local Address:Port                                                Peer Address:Port 
LISTEN      0      128                                                     127.0.0.1:9966                                                           *:*      
users:(("ssh",pid=10714,fd=5))
LISTEN      0      128                                                     127.0.0.1:8080                                                           *:*      
users:(("ssh",pid=10714,fd=4))
LISTEN      0      128                                                             *:80                                                             *:*      
users:(("lighttpd",pid=28487,fd=5))
LISTEN      0      128                                                             *:631                                                            *:*      
users:(("cupsd",pid=25898,fd=10))
LISTEN      0      128                                                     127.0.0.1:9944                                                           *:*      
users:(("ssh",pid=10714,fd=6))
LISTEN      0      128                                                     127.0.0.1:8088                                                           *:*      
users:(("ssh",pid=4357,fd=5))
LISTEN      0      128                                                     127.0.0.1:9945                                                           *:*      
users:(("ssh",pid=10714,fd=8))
LISTEN      0      128                                                     127.0.0.1:2299                                                           *:*      
users:(("ssh",pid=4357,fd=7))
LISTEN      0      128                                                     127.0.0.1:2525                                                           *:*      
users:(("ssh",pid=10714,fd=9))
LISTEN      0      128                                                     127.0.0.1:9955                                                           *:*      
users:(("ssh",pid=10714,fd=7))
LISTEN      0      128                                                     127.0.0.1:3306                                                           *:*      
users:(("ssh",pid=10283,fd=5))
LISTEN      0      128                                                     127.0.0.1:11211                                                          *:*      
users:(("memcached",pid=1040,fd=26))
LISTEN      0      128                                                            :::631                                                           :::*      
users:(("cupsd",pid=25898,fd=11))
LISTEN      0      128                                                           ::1:8088                                                          :::*      
users:(("ssh",pid=4357,fd=4))
LISTEN      0      128                                                           ::1:2299                                                          :::*      
users:(("ssh",pid=4357,fd=6))
LISTEN      0      128                                                           ::1:3306                                                          :::*      
users:(("ssh",pid=10283,fd=4))

[pavlix]

Detail. :)

[Michal Kubeček]

Hm…

lion:~ # netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
PID/Program name   
tcp        0      0 0.0.0.0:3551            0.0.0.0:*               LISTEN      
1951/apcupsd        
tcp        0      0 213.168.178.121:6881    0.0.0.0:*               LISTEN      
16109/ktorrent      
tcp        0      0 0.0.0.0:902             0.0.0.0:*               LISTEN      
7698/vmware-authdla 
tcp        0      0 0.0.0.0:8010            0.0.0.0:*               LISTEN      
5735/psi-plus       
tcp        0      0 172.16.161.1:139        0.0.0.0:*               LISTEN      
2850/smbd           
...

[Jendа]

Mně to prostě na terminálu širokém 157 znaků dělá toto. netstat má fixní šírku, ss se takhle debilně roztáhne.

[Jendа]

Admin chce prostě IPsec tunel mezi dvěma sítěmi - ano přesně ten tunel který si pod pojmem tunel každý admin představí.

Já nechci ipsec tunel. Na tunelování je tady spousta jiných protokolů. Já chci ipsec na šifrování.

[pavlix]

Pokud vím, tak security policy přesně určuje, kudy paket odejde, a když to máš určeno tou security policy, tak se už směrovací tabulka pro ten vnitřní paket tunelu neuplatní. Tedy ve své podstatě je takový security záznam přímou náhradou směrovacího záznamu. Jestli se chceš o tom dál bavit, tak prosím vynech ulítlá přirovnání a argumentuj rovnou k věci.

[Michal Kubeček]

Pokud vím, tak security policy přesně určuje, kudy paket odejde, a když to máš určeno tou security policy, tak se už směrovací tabulka pro ten vnitřní paket tunelu neuplatní.

Pokud je řeč o tunnel mode, tak tam se samozřejmě routing pro zapouzdřený paket neuplatní, to by nedávalo smysl. Ale routing se aplikuje na ten výsledný paket podle vnější IP hlavičky a funguje naprosto standardním způsobem. U transport mode je to ještě jednodušší, tam je hlavička jen jedna a podle té se to routuje.

Jestli se chceš o tom dál bavit, tak prosím vynech ulítlá přirovnání a argumentuj rovnou k věci.

Já na tom přirovnání nevidím nic ulítlého. V obou případech mám dvě vrstvy a výstup první slouží jako vstup pro druhou, takže ovlivní i její výsledek, ale až zprostředkovaně.

[pavlix]

Pokud je řeč o tunnel mode, tak tam se samozřejmě routing pro zapouzdřený paket neuplatní, to by nedávalo smysl.

Od začátku není řeč o ničem jiném než kudy půjde běžný paket. U ostatních VPN systémů se to řeší virtuálním rozhraním a záznamem ve směrovací tabulce, kernel ipsec virtuální rozhraní nenabízí a vyžaduje záznam ve vlastní tabulce. Jsou to dva relativně odlišné přístupy, z nichž každý má své výhody a příznivce.

[Michal Kubeček]

Sice z teoretickeho hlediska je to mozna navrzene ciste a pokrokove, ale z pohledu cloveka co se o takovy router ma starat je to fakt voser. … Byvaly doby kdyz kazdy ipsec tunel byl normalni interface

Už vidím, jak by z takového návratu ke kořenům byl nadšený ten zákazník, pro kterého jsem onehdy řešil bug projevující se v okamžiku, kdy v namespace vyrobili 19000 SP and pak ho shodili.

ale to bylo mozna jeste ve 2.4.x.

Ano, ve 2.4, když ještě v mainline jádře žádná podpora IPsec nebyla a používal se FreeS/WAN, kde implementaci zajišťoval z části third party modul (KLIPS) a z části userspace démon (Pluto).

[yupa]

Jako nic proti, ale proč článek "Jaderné noviny – 4. 2. 2015: Linux jako single-user systém" vyšel až 4.5.2015 v 16:35?

[Nonsence]

Jsme ve skluzu, snažíme se to dohnat. V následujících měsících by měly vycházet jaderné noviny dvakrát týdně.

[Qaxi]

To je jednoduché.

Nepřeložil jsi ho! (... a ještě pindáš když to někdo udělá)

Tímto děkuji autorovi za článek s přehledem o kernelu a za překladateli za překlad.

[linuxtardis]

Připojíte-li Rasberry Pi k modernímu velkému disku, je velká šance, že na chytřejším konci kabelu se nachází ten disk

Autor původně chtěl říct, že chytřejší je disk než RPi, a ne konektor kabelu (pokud to není optika :)

[Roger]

On je špatně přeložený i ten druhý cítát...

[Kurama]

Kupodivu jsem to tak i z té věty pochopil. :-/

[Jendа]

vložený operační systém

[pavlix]

Tak ono je debilní i to slovo v originále, i jeho lepší překlady do češtiny, ale fakt je, že už jsme si na to tak nějak zvykli.

[kozzi]

Nejak nevidi zdroj a odkaz na original?

[pavlix]

Taky jsem právě nemohl najít.

[Nonsence]

Díky za postřeh, opraveno

[radek]

Co vadí na slově jednouživatelský, že jste ho nepoužili? To zní výjimečně i docela rozumně.

[pc2005]

Připojíte-li Rasberry Pi k modernímu velkému disku, je velká šance, že chytřejší zařízení na konci kabelu je ten disk.

- Alan Cox

P.S. Užitečná citace, bez ní by mě nedocvaklo, že "One Thousand Gnomes" je nickname AC.