Názory k článku Nástroj apt-key končí. Jak dál spravovat klíče balíčkovacího systému?

Přemýšlím, co se tím reálně řeší. Ano, dnes klíč může podepisovat libovolný repozitář, což nevypadá hezky. Ale zároveň pokud z toho repozitáře mám nainstalovaný aspoň jeden balíček (docela důvodný předpoklad), pak stejně může mít instalační skripty spouštěné s právy roota. Případně může „upgradovat“ balíčky z jiných repozitářů. Návrhově nové řešení vypadá lépe, prakticky v tom ale přínos nevidím. Možná něco přehlížím, možná jde i přípravu na další změny, se kterými to začne dávat větší smysl.

Nemusí být kompromitovaný repozitář, ale jen jeho klíč.
To otevírá cestu k dalším zneužitím. Např. s klíčem z jednoho repozitáře kompromitujete jiný repozitář, ke kterému máte přístup (třeba k DNS), ale zase chybí klíč. Nebo pokud se Vám podaří udělat "jen" http redirect - pak nemusíte mít přístup ani k jinému repozitáři, ani práva roota, stačí ten klíč.

Celému tomu mechanismu (starému i novému) bych spíš vyčítal uživatelskou nepřívětivost. Uživatelé sázejí do APT klíče podle kuchařek na internetu - bez přemýšlení. Ke skutečnému ověření dochází jen málo (ano, ti, kdo chtějí, tak mohou - ale mluvím o BFU). Nyní se aspoň změní to, že v internetových kuchařkách budou návody jen k tomu, jak si bezmyšlenkovitě přidat klíč k jednomu jedinému repozitáři.

Good point.

Ad kuchařky - jako jo, na druhou stranu moc dobré řešení nevidím. Možná něco ve stylu Ubuntu PPA, případně něco více decentralizovaného, kde by klíč byl součástí URL.

Podle mě by dávalo smysl, aby se ústředně evidovaly důvěryhodné klíče repozitářů a vazba klíč-oprávnění-repozitář. Přičemž důvěryhodnost by neznamenala, že je obsah nezávadný, ale že jeho správce je identifikovaný a znám. To je totiž - podle mě - takový základ, nad kterým se dá hovořit o řetězci důvěryhodnosti.

Pokud to necháme na kuchařkách, tak celý ten systém je podkopaný už svým základním nastavením. Pak už totiž můžeme uvažovat i takto: Pokud je ten systém ověřování prospěšný jen pro profesionální uživatele a laikům neslouží - je tedy opravdovým přínosem právě vylepšení v navázání klíče na konkrétní repozitář? Neoddálí to naopak laiky od bezpečného užívání?

A to už jsou asi legitimní otázky. Nyní se objeví návody, jak se bezmyšlenkovitě vrtat přímo v nastavení repozitářů APT - tj. činnost možná ještě o stupínek závažnější, než byla aktualizace klíče přes apt-key.

Aby to nebylo podle slavné věty "mysleli jsme to dobře, ale dopadlo to jako obvykle."

Ted to neresi vubec nic. Mozna se v budoucnosti omezi skripty a cesty v deb, coz by bezpecnost alespon castecne resilo.

Na zabraneni upgradu jsou apt preferences, kde si muzes pinovat repo pro jiste baliky. Necht se treba deb z Google repa pouziji jen kdyz systemove baliky chybi; google-chrome-stable by se odsud stahoval vzdy.

Nejak asi nechapu, co se tim resi. Pokud budu mit repozitar repo.example.com a do repo file mu pridam dany klic, porad tomu klici verim pro vsechny baliky daneho repa. Co zabrani tomu, aby se v tom repu neobjevil treba balik linux-image-10.0.0.deb, ktery bude obsahovat skodlivy kod a system ho bude povazovat za upgrade kernelu? Na to preci mame pinning, abychom vazali baliky na konkretni repo, ne klice. Ano, asi to resi situaci, kdy nekdo ukradne klic repozitare A, podepise tim svuj balik a nahraje ho do repozitare B, ale proc by to nekdo delal, kdyz uz ma pristup k repozitari A? Vlastne by to byla i kravina - lidi co maji klic k repu A maji pravdepodobne i repo A, lidi co maji pouze repo B pravdepodobne nemaji ani klic k repu A a apt zarve chybu podpisu.

22. 6. 2021, 08:30 editováno autorem komentáře

Dejme tomu, že repozitář A půjde přes HTTP, ale nebudu k němu mít klíč. Repozitář B půjde přes HTTPS, ale budu k němu mít klíč. Co mohu z pozice útočníka?

Dnes mohu udělat MITM k repozitáři A a podepsat to klíčem repozitáře B. Analogická situace nastává, když z nějakého důvodu sice nemohu udělat MITM (HTTPS, nemám přístup k síti, …), ale kompromitoval jsem infrastrukturu jiného repozitáře, než ke kterému mám klíč.

Bude-li klíč vázaný k repozitáři, podobný útok nebude možný – musel bych kompromitovat spojení nebo infrastrukturu ke stejnému repozitáři.

Taky nechápu, co tím řeší.

Jsem padouch, nabořím server hostující repo a zmocním se klíče k repu, vyberu nějaký modul dostupný i se zdrojákem, zvýším číslo revize, do instalačního skriptu dopíšu "apt-get install -y super-ransom-crypto". Nebo, protože ten skript valí pod rootem, se povrtat v databázi klíčů a vyměnit tam cokoliv.

V tu chvíli je úplně šumák, že nemůžu napadnout žádný jiný repo, protože na stroji oběti jsem na chvíli root a není, co bych nemohl...

Výměnu klíče jinýho repa skriptem by řešilo jenom mít extra uživatele na update a dát mu klíče jako read only... A to by šlo i se stávajícím řešením.

Da se to zkombinovat s apt pinningem (/etc/apt/pre­ferences.d), imho by mely mit vsechny 3rd party repozitáře nižší prioritu by default a třeba pomocí pinningu si určit, které balíky z toho repozitáře nainstalovat. Viděl jsem balíky, které "v dobrém umyslu" v postinstu bez vědomí uzivatele přidali apt klíč a cron na automatické updaty. To mi třeba vadí hodně. To, že v takovém případě ten klíč nebude platný globálně, mě pomůže, protože zbytek umím vyřešit právě pinningem. (Ještě by to ten pinning chtělo nějak chytře automatizovat.)

Napr. apt by si mohlo pamatat, ze z ktoreho repa je balik nainstalovany a by defult brat update aj dependencie z rovnakeho repa. Spolu s tym, ze podpis je platny len pre jedno repo to uz aj realne trochu obmedzi moznosti utoku.

Co mi to připomíná? Jo aha, už vím: I'm giving up on PGP. Pro 99% lidí je tohle podepisování jen otravná blbost komplikující užívání.

Solidní softy pro linux každému připraví rovnou shell instalaci, která apt-key prostě buď použije nebo ne někde uvnitř a uživatele to vůbec nezajímá.

Typicky

$ curl -fsSL https://muj-uzasni.soft/linux-install | sudo -E bash -
$ sudo apt-get install -y muj-soft

Důvěřuji https://muj-uzasni.soft, tak pastuju a nazdáár.

Jinak apt-key je shellovina, která se od roku 2018 prakticky nezměnila, takže asi stačí forknout a používat dál pokud chci a nemám obavy.

Pokud copy pasta návody také upgradnou tak, aby tam apt-key nebylo, tak v poho. Osobně jsem nikdy apt-key samo o sobě neřešil, vždycky jen copy pasta kvůli nějakým 3rd party balíčkům.

Solidní softy pro linux každému připraví rovnou shell instalaci

Nejspíš máme odlišnou definici slova "solidní", jelikož podobný způsob instalace sw považuji za prasárnu a bezpečnostní riziko.

Jako správce debianího repozitáře mě to zajímá a děkuji panu Krčmáři za zdvihnutí leckdy opomíjeného tématu.

Instrukce pro přidání jsem samozřejmě upravil.

https://repo.vitexsoftware.cz/

Moc se mi libi obrazek u apt-repo-sury :-)

http://repo.vitexsoftware.cz/imgdeb/apt-repo-suryorg.png

Zajimavejsi by bylo, kdyby slo k danemu klici uvest nejen repozitar, pro ktery ten klic plati, ale taky seznam balicku. Abych mohl rict, ano mplayer (+ libdvd, libavi a spol) chci z nejake neoficialniho repa, ale glibc nikoliv.

To se permisivním způsobem řeší přes pinning. Jakou výhodu byste viděl navíc v těsném spjatí s klíčem?

Jo klidne pres pinning. To je jedno jestli klic nebo pinning. Ale kdykoliv jsem pinning nastavoval tak jsem nad tim pul dne dumal jak to nastavit _spravne_, a stejne si nebyl jist vysledkem.

Jde mi o to aby byl "BFU friendly" nastroj (klidne jako text config, nemusi byt klikaci, ale jednoduse srozumitelny), kterym lze rict:

1) Ktery klic podepisuje ktery repozitar - to je vyresene postupem dle clanku
2) Ktere balicky existujici v distribuci muze dany repozitar preinstalovat vlastni verzi. A muselo by byt vynucene, ze pokud neni explicitne uvedeno nic, tak ma smulu a nemuze nic upgradnout. Podobne jako maji myslim backports a experimental, ale tam je to nastaveno na strane repozitare. Tohle by muselo byt na strane uzivatele a jakykoliv pinning ze strany repozitare zvysujici prioritu by mel byt ignorovan.

Nebo lépe, dát uživateli na výběr. Podobně jak windows uac. Selhat jen v batch režimu. Když si to uživatel nenakonfiguruje, tak by se to zeptalo, že tu má tyhle balíky z 3rd party, podepsaného repozitáře. Jestli se mají nainstalovat.

Praci s repozitari velmi miluji v automatizaci. Takovych problemu...

Neustale reseni zmeny klicu pro repo, kdyz dane repo je zavislost pro konfiguraci dane sluzby.

Nebo dnes. Repo pro php od sury.org zmenilo jeden z flagu, tak mi apt secure rval, ze musim explicitne potvrdit tu zmenu. Velmi vitana vec, kdyz to rozbije automatizaci.