abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 15:22 | Pozvánky

V sobotu 24. 2. se uskuteční již 5. ročník největší české WordPress konference – WordCamp Praha 2018. Pražský WordCamp bude rozdělen na dva proudy – pro uživatele a pro vývojáře. Je naplánováno 10 přednášek, 6 workshopů, 6 případových studií, Happines Bar a spousty příležitostí pro networking. V neděli se bude dále konat Contributing Day, kde se každý bude moci aktivně zapojit do překladu, či plánování dalších meetupů. Je připraveno 450

… více »
smíťa | Komentářů: 0
včera 05:55 | Komunita

Linus Torvalds oznámil vydání Linuxu 4.15-rc9. Po vydání stabilní verze Linuxu se přibližně na 2 týdny otevře začleňovací okno. To se uzavře vydáním verze rc1. Po týdnech následují další rc verze. Obvykle týden po vydání verze rc7 nebo rc8 následuje vydání nové stabilní verze Linuxu. Verze rc9 byla naposledy vydána před více než 6 lety, 4. října 2011. Jednalo se o Linux 3.1. Tenkrát následovala ještě verze rc10.

Ladislav Hagara | Komentářů: 13
21.1. 21:55 | Zajímavý článek

Greg Kroah-Hartman se v příspěvku na svém blogu věnuje aktuálnímu stavu řešení bezpečnostních chyb Meltdown a Spectre v Linuxu. Jak je na tom Váš Linux? Stačí spustit příkaz "grep . /sys/devices/system/cpu/vulnerabilities/*". Pro více informací lze doporučit Spectre & Meltdown Checker.

Ladislav Hagara | Komentářů: 46
19.1. 18:55 | Komunita

NHSbuntu (Joinup, prezentace) měla být z Ubuntu vycházející linuxová distribuce přizpůsobená pro potřeby britské Národní zdravotní služby (NHS). NHS se název nelíbil, nejednalo se o oficiální projekt NHS, a proto bylo NHSbuntu v září loňského roku přejmenováno na NHoS. Vývojáři NHoS tento týden oznámili, že NHS se nelíbí ani název NHoS a už nemají sílu na další přejmenování a pokračování v projektu. Dodávají, že několik jednání s vedením

… více »
Ladislav Hagara | Komentářů: 7
19.1. 18:44 | Pozvánky

Koncem ledna, 29. 1. 2018 od 17 do 20 hodin se v Akademii CZ.NIC uskuteční večer s Turrisem.

Co bude na programu?… více »
Miška | Komentářů: 19
19.1. 18:33 | Pozvánky

Na tri dni sa hlavné mesto Slovenska po tretíkrát zmení na miesto s najväčšou koncentráciou profesionálnych programátorov, systémových administrátorov, učiteľov informatiky aj technologických nadšencov. Hlavným lákadlom bude konferencia PyCon SK 2018, určená záujemcom o Python, jeden z najpopulárnejších programovacích jazykov na svete.

… více »
RicCo386 | Komentářů: 1
19.1. 18:22 | Pozvánky

Letošní ročník konference Prague PostgreSQL Developer Day se koná ve dnech 14. 2. a 15. 2. 2018. Zveřejněn byl program s přednáškami a školeními. Otevřena byla také registrace na konferenci.

TomasVondra | Komentářů: 0
19.1. 11:33 | Komunita

Společnost Canonical stojící za linuxovou distribucí Ubuntu oznámila dostupnost nástroje pro týmovou spolupráci Slack (Wikipedie) ve formátu snap. Instalovat jej lze ze Snapcraftu. Slack pro Linux je dostupný také ve formátu klasických balíčků pro Ubuntu a Fedoru.

Ladislav Hagara | Komentářů: 10
18.1. 17:33 | Nová verze

Po roce vývoje od vydání verze 2.0 a 6 000 změnách byla vydána nová stabilní verze 3.0 softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem, Wine (Wikipedie). Z novinek lze zdůraznit například podporu Direct3D 10 a 11. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 15
18.1. 13:44 | Zajímavý projekt

V říjnu loňského roku úspěšně skončila kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů. Společnost Purism informuje o aktuálním vývoji tohoto telefonu. Místo plánovaného SoC i.MX6 by měl být použit úspornější i.MX8.

Ladislav Hagara | Komentářů: 6
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (7%)
 (1%)
 (1%)
 (1%)
 (77%)
 (13%)
Celkem 1372 hlasů
 Komentářů: 53, poslední 17.1. 16:55
    Rozcestník

    Jaderné noviny – 7. 12. 2017: Omezení automatického zavádění jaderných modulů

    27. 12. 2017 | Redakce | Jaderné noviny | 1740×

    Stav vydání jádra. Citáty týdne: Thomas Gleixner a Matthew Wilcox. Omezení automatického zavádění jaderných modulů.

    Stav vydání jádra

    Současné vývojové jádro je 4.15-rc2, vydané 3. prosince. Linus řekl: „Jedna věc, na kterou chci poukázat, je, že se snažím dosáhnout ucpání nějakých úniků ASLR a do toho spadá, že nyní ve výchozím stavu hašujeme všechny ukazatele vypsané pomocí ‚%p‘. Mnoho lidí to neovlivní, ale kde půjde o problém s laděním (spíš než únik zajímavých ukazatelů z jádra), tam to budeme muset opravit.“

    Stabilní aktualizace: 4.14.3, 4.9.66, 4.4.103 a 3.18.85 vyšly 30. listopadu. Následovaly je aktualizace 4.14.4, 4.9.67, 4.4.104 a 3.18.86, a to 5. prosince.

    Citáty týdne, tentokrát o názvech

    Několik lidí včetně Linuse požádalo o změnu názvu KAISER. Dali jsme dohromady seznam technicky správných akronymů:

    User Address Space Separation, prefix uass_

    Forcefully Unmap Complete Kernel With Interrupt Trampolines, prefix fuckwit_

    Ale jsme politicky korektní, takže jsme se shodli na

    Kernel Page Table Isolation, prefix kpti_

    Linusi, výběr je na tobě :)

    Thomas Gleixner

    Nejsem rozhodnutý pro MAP_REQUIRED. Vymyslel jsem několik ošklivých jmen (MAP_TODDLER, MAP_TANTRUM, MAP_ULTIMATUM, MAP_BOSS, MAP_PROGRAM_MANAGER atd.). Ale myslím si, že by se z prostředku jména mělo vyhodit slovo FIXED.

    Matthew Wilcox

    Omezení automatického zavádění jaderných modulů

    Restricting automatic kernel-module loading. Jonathan Corbet. 4. prosince 2017

    Mechanismus jaderných modulů umožňuje sestavení jádra s podporou široké škály hardwaru a softwaru, aniž by všechen ten kód musel být načten do každého běžícího systému. Z dostupnosti všech modulů v typickém distribučním jádře plyne, že k dispozici je mnoho funkcí, ale potenciálně také mnoho zneužitelných chyb. Objevila se celá řada případů, kdy došlo k použití automatického zavádění jaderných modulů, aby se do běžícího systému natáhl chybný kód. Na pokusu omezit expozici jádra modulům s chybami se ukazuje, jak náročné mohou být některé druhy tvrdících prací.

    Automatické zavádění modulů

    Jsou dva způsoby, jak lze do jádra načíst modul bez explicitního zásahu ze strany správce. Na většině současných systémů k tomu dojde, když je detekován (discovered) nový hardware – buď ovladačem sběrnice (na sběrnicích, které podporují detekci nového hardwaru), nebo z externího popisu, jako je strom zařízení. Detekce způsobí zaslání události do uživatelského prostoru, kde démon jako udev aplikuje jakákoli nastavená pravidla a zavede příslušné moduly. Tento mechanismus je řízen dostupností hardwaru a pro útočníka je relativně těžké nějak ho ovlivnil.

    V jádře se ale skrývá starší mechanismus, který má podobu funkce request_module(). Když některá jaderná funkce sezná, že chybí potřebný modul, může zavolat request_module(), aby do uživatelského prostoru vyslala požadavek na zavedení příslušného modulu. Například pokud aplikace otevře znakové zařízení s daným hlavním (major) a vedlejším (minor) číslem a pro tato čísla neexistuje žádný ovladač, kód znakového zařízení se pokusí ovladač vyhledat následujícím voláním:

    request_module("char-major-%d-%d", MAJOR(dev), MINOR(dev));

    Pokud má modul ovladače nastavený alias s odpovídajícími čísly, bude automaticky zaveden do jádra, aby byl zpracován otevřený požadavek.

    V jádře se nacházejí stovky volání request_module(). Některé případy jsou docela konkrétní: jeden například načte modul ide-tape, když má uživatel tu smůlu, že disponuje dotyčným zařízením. Jiné jsou obecnější: v síťovém subsystému je mnoho volání například k nalezení modulů implementujících určité síťové protokoly nebo mechanismy filtrování paketů. Zatímco volání specifická pro konkrétní zařízení byla většinou nahrazena mechanismem udev, moduly funkcí, jako jsou síťové protokoly, stále spoléhají na automatické zavádění, které je z pohledu uživatelů transparentní, pomocí request_module().

    Automatické zavádění zajišťuje pohodlnou správu systému, ale zároveň jeho pohodlné zneužití. Zranitelnost protokolu DCCP, která byla zveřejněna v únoru, se nedá zneužít, pokud není modul načten do jádra – což běžně nebývá, protože DCCP má málo uživatelů. Jenže mechanismus automatického načítání umožňuje libovolnému uživateli vynutit si zavedení tohoto modulu prostým vytvořením DCCP soketu. Automatické zavádění tedy rozšiřuje možnosti útoku na jádro na cokoli, co mohou neprivilegovaní uživatelé načíst – a v běžné distribuci jádra je takových modulů hodně.

    Utahování systému

    Djalal Harouni pracuje na sadě patchů zaměřené na omezení vystavení jádra zranitelnostem způsobeným automatickým načítáním. Zatím nejnovější verze byla zveřejněna 27. listopadu. Harouni se inspiroval tvrzením v sadě patchů grsecurity, z ní si ale nebere žádný kód. V této podobě (která se v průběhu času poněkud změnila) přidává novou volbu sysctl (/proc/sys/kernel/modules_autoload_mode), která se dá použít k omezení jaderného mechanismu automatického zavádění modulů. Pokud je volba nastavena na nulu (výchozí nastavení), funguje automatické zavádění stejně jako na současných jádrech. Změna nastavení na jedničku omezí zavádění na procesy s určitými schopnostmi (capabilities): procesy s CAP_SYS_MODULE mohou způsobit zavedení libovolného modulu, zatímco ty s CAP_NET_ADMIN mohou nahrát libovolný modul, jehož alias začíná na netdev-. Nastavení volby na dvojku zakáže automatické zavádění úplně. Jakmile je hodnota nastavena na více než nulu, nelze ji po dobu životnosti systému zase snížit.

    Tato sada patchů implementuje i příznak, který může být nastaven jednotlivým procesům, a to pomocí systémového volání prctl(). Tento příznak (který akceptuje stejné hodnoty jako globální příznak) může určitému procesu a všem jeho potomkům omezit možnost automatického zavádění modulů, aniž by došlo ke změně chování v zavádění modulů v celém systému.

    Dá se s jistotou říct, že tato sada patchů nebude ve své stávající podobě začleněna, a to z jednoho důvodu: Linusi Torvaldsovi se vůbec nelíbila. Zákaz automatického zavádění modulů pravděpodobně rozbije mnoho systémů, což znamená, že distributoři nebudou ochotni tuto volbu nastavit, takže se nebude moc využívat. „Bezpečnostní volba, kterou uživatelé nemohou použít, aniž by si rozbili systém, je naprosto zbytečná,“ řekl. Diskuze na toto téma se občas vyostřila, ale Torvalds proti myšlence omezit vystavení jádra automaticky zavedeným zranitelnostem, nic nemá. Jde pouze o to najít správné řešení.

    Zdá se, že řešením by mohly být právě příznaky pro konkrétní procesy. Daly by se použít například k omezení automatického zavádění modulů z kódu běžícího v kontejneru, zatímco systém jako takový by zůstal beze změny. Není neobvyklé uvnitř kontejneru vytvořit proces se schopností CAP_NET_ADMIN k nastavení přístupu kontejneru k síti a zároveň chtít, aby si většina kódu v kontejneru nemohla vynutit zavádění modulů.

    Ale jak řekl Torvalds, jediný příznak nebude nikdy schopen patřičně pokrýt všechny situace, kdy automatické zavádění hraje roli. Některé moduly by možná mělo být možné načíst vždy, zatímco jiné mohou vyžadovat nějakou konkrétní schopnost. Takže navrhl funkci request_module_cap() z Harouniho sady patchů (která provede zavedení pouze tehdy, když je k dispozici konkrétní schopnost) zachovat a používat ji šířeji. Na druhou stranu si vyžádal několik změn.

    První z nich je, že request_module_cap() by ve skutečnosti neměla blokovat zavádění modulů, když požadovaná schopnost chybí – alespoň ne zpočátku. Místo toho by funkce měla zaznamenat zprávu. Umožní to zjistit, ve kterých případech je automatické zavádění opravdu zapotřebí, což by se štěstím mohlo poukázat na místa, kde je možné ho omezit bez rozbití existujících systémů. Navrhl také, že kontrola schopností je příliš zjednodušující. Například výše popsané automatické zavedení „char-major-“ nastane pouze tehdy, je-li proces schopen otevřít uzel zařízení s uvedeným hlavním a vedlejším číslem. V takových případech již byl úspěšně proveden test oprávnění (schopnost otevřít speciální soubor) a modul by měl být bezpodmínečně zaveden. Takže možná budou zapotřebí další varianty request_module() k popisu případů, na které se schopnosti nevztahují.

    Nakonec měl Linus Torvalds další nápad, který se týkal myšlenky, že nejhorší chyby se obvykle ukrývají v modulech, které jsou spravovány přinejlepším bídně. Například o modulu DCCP zmíněném výše je známo, že se využívá zřídka a je téměř neudržovaný. Pokud by dobře udržované moduly byly označeny zvláštním příznakem, mohlo by jít omezit neprivilegované automatické zavádění pouze na tyto moduly. Tím by se zabránilo automatickému zavádění některých spíše zbytných modulů, aniž by došlo k narušení automatického zavádění jako takového. Tato myšlenka vyvolává jednu otázku, kterou nikdo nepoložil: Pokud modul přestane být udržován, kdo se postará o to, aby byl smazán příznak „dobře udržovaný“?.

    V každém případě nebude tento příznak přidán hned, bude-li platit plán navržený Keesem Cookem. Ten navrhl začít s request_module_cap() s povolenými varováními. Příznaky pro jednotlivé procesy by byly přidány pro ty, kteří je mohou používat, ale globální volba k omezení automatického zavádění by přidána nebyla. Nakonec by mohlo být možné zbavit se neoprávněného zavedení modulu, ale to je cíl do budoucna. Krátkodobými přínosy by byla jednak lepší znalost toho, jak se automatické zavádění skutečně používá, a jednak možnost volby pro správce, kteří chtějí systém utěsnit již nyní, aby mohli omezit jednotlivé procesy.

    Tato debata zvýrazňuje jedno ze základních pětí kolem práce na tvrzení jádra. Jen málo lidí je proti bezpečnějšímu jádru, ale situace se komplikuje, jakmile může tvrzení rozbít stávající systémy, což se často stává. Vývojáři orientovaní na zabezpečení jsou často frustrováni tím, že se jaderná komunita brání změnám v tvrzení s viditelnými dopady na uživatele, zatímco jaderní vývojáři mají málo sympatií pro změny, které povedou k nahlášeným chybám a nešťastným uživatelům. Některé projevy takové nespokojenosti se v této diskuzi ukázaly, ale většina zúčastněných vývojářů měla vesměs zájem spolupracovat na řešení, které by fungovalo pro všechny.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.