Tartalom

Bevezető

Debian vagy Ubuntu alapú szervereink, rendszereink karbantartásának egyik alapvető, rendszeresen visszatérő feladata a csomagtárak és a telepített szoftverek frissítése. Egy apt update és apt upgrade (vagy apt full-upgrade) parancs általában gyorsan és zökkenőmentesen lefut, biztosítva rendszerünk biztonságát és naprakészségét. Azonban, ahogy a mondás is tartja, az ördög néha a részletekben rejlik.

A napokban épp a szerveremen végeztem a szokásos frissítési kört, ami mostanában kicsit elmaradt, így számítottam rá, hogy több csomag is frissülni fog. Ilyenkor, főleg ha külső, harmadik féltől származó tárolókat is használunk (mint például a népszerű Sury.org tároló a PHP verziókhoz), nagyobb eséllyel bukkanhatunk váratlan üzenetekre, figyelmeztetésekre. Így is történt: a frissítési folyamat érdekes üzenetekkel állt meg, amelyek a csomagtárak aláírókulcsainak kezelésével kapcsolatos fontos változásra hívták fel a figyelmet.

Ebben a leírásban lépésről lépésre bemutatom, milyen üzenetekkel találkoztam, mi a háttérben zajló változás lényege, és hogyan orvosolhatjuk a helyzetet, hogy a frissítések a jövőben is gördülékenyen menjenek végbe.

A probléma - signed-by figyelmeztetések frissítéskor

A csomagfrissítések során gyakran találkozhatunk többféle figyelmeztetéssel, amik hasznos információkkal szolgálnak az esetleg szükséges azonnali vagy későbbi teendőkről.

Ezek közül ebben az esetben ezek kerültek elő:

Az apt-listchanges figyelmeztetése

A csomagfrissítések során gyakran találkozhatunk az apt-listchanges nevű eszközzel. Ez egy hasznos segédprogram, amely a frissítésre váró csomagok változásjegyzékét (changelog) jeleníti meg, mielőtt a tényleges frissítés megtörténne. Így lehetőségünk van áttekinteni, hogy milyen újdonságok, változások várnak ránk az új csomagverziókban. Az apt-listchanges üzenetei általában a "News" (Hírek), "Changes" (Változások) és "TODO" (Teendők) szekciókra vannak osztva.

Az általunk tapasztalt figyelmeztetés a "News" szekcióban jelent meg, közvetlenül a frissítési folyamat elején. Íme a képernyőkép, amelyen ez látható:

A képen jól látható a figyelmeztető üzenet, amely a debsuryorg-archive-keyring csomaghoz kapcsolódik. A legfontosabb részei az üzenetnek a következők:

• global APT key will been removed in the next update of the package: Ez a mondat jelzi a változás lényegét: a korábban a /etc/apt/trusted.gpg.d/debsuryorg-archive.gpg helyen tárolt, globálisan megbízható APT kulcs a csomag következő frissítésével el fog tűnni.
• You need to manually add: [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg]: Ez pedig a teendőt fogalmazza meg: manuálisan hozzá kell adnunk a [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] direktívát az APT forráslistáinkhoz.

Az üzenet továbbá utal egy Debian Wiki oldalra is, ahol további információkat találhatunk a témában. Fontos megértenünk, hogy ez nem hibaüzenet a szó szoros értelmében, hanem egy figyelmeztetés, amely egy közelgő változásra készít fel minket, és a szükséges lépéseket is közli.

A debconf párbeszédablak figyelmeztetése

Előfordulhat, hogy a frissítési folyamat során nem az apt-listchanges eszközben, hanem közvetlenül a csomagok telepítése vagy frissítése közben találkozunk a figyelmeztetéssel. Ilyenkor a debconf nevű konfigurációs rendszer jeleníti meg az üzenetet egy párbeszédablakban. A debconf a csomagok telepítése során teszi lehetővé, hogy a felhasználó beállításokat adjon meg, vagy megerősítsen bizonyos döntéseket.

A signed-by direktívával kapcsolatos figyelmeztetés akkor jelenik meg debconf ablakban, amikor a debsuryorg-archive-keyring (vagy egy hasonló kulcscsomag) kerül frissítésre, és a rendszer észleli, hogy a tárolóhoz tartozó forráslista bejegyzés még nem tartalmazza a megfelelő "signed-by=" direktívát. Íme egy példa erre, ami nálam is éppen előjött:

A debconf üzenet lényegében ugyanazt a figyelmeztetést közli, mint az apt-listchanges, csak egy másik formában, a csomagtelepítés közben. A teendőnk ugyanaz: módosítani kell a forráslistát.

Miért kapjuk ezeket a figyelmeztetéseket? A háttér

Most, hogy láttuk a figyelmeztető üzeneteket és azok tartalmát, ideje megvizsgálnunk, miért is van szükség erre a változásra. A következőkben áttekintjük a régi és az új módszert a csomagtárak kulcsainak kezelésére, valamint azt, hogy miért jelent a signed-by direktíva biztonságosabb megoldást a korábbiakhoz képest.

A régi, elavult módszer: /etc/apt/trusted.gpg.d

A Debian alapú rendszereken a harmadik féltől származó csomagtárak GPG kulcsait hagyományosan az /etc/apt/trusted.gpg.d/ könyvtárban tároltuk. Ez a könyvtár tartalmazza azokat a kulcsfájlokat, amelyekkel a rendszer ellenőrzi a csomagok hitelességét a frissítések során.

Ha egy új tárolót adtunk hozzá a rendszerhez, a hozzá tartozó GPG kulcsot általában letöltöttük, majd ebbe a könyvtárba másoltuk be. Ezzel a kulcs globálisan megbízhatóvá vált, ami azt jelentette, hogy a rendszer minden tároló esetében elfogadta ezt a kulcsot a csomagok hitelesítésére.

Ez a módszer egyszerű és könnyen használható volt, azonban mára elavultnak számít, és a jövőben a signed-by direktíva váltja fel teljesen.

Az új, biztonságosabb módszer: A signed-by direktíva

A régi, globális kulcskezelés helyett az APT egy új, biztonságosabb módszert vezetett be a csomagtárak hitelesítésére: a signed-by direktívát. Ezt a direktívát a forráslistákban (a /etc/apt/sources.list fájlban, vagy a /etc/apt/sources.list.d/ könyvtárban található .list fájlokban) kell megadni, a tároló definíciójának a részeként.

A signed-by direktíva expliciten összekapcsol egy adott tárolót egy adott GPG kulccsal. Ez azt jelenti, hogy a rendszer csak akkor fogadja el a tárolóból származó csomagokat, ha azokat a megadott kulccsal írták alá.

A direktíva szintaxisa a következő:

deb [signed-by=/elérési/út/a/kulcshoz.gpg] https://tároló.címe/ disztribúció komponens

Ahogy a korábbi példákban (és a figyelmeztető üzenetekben) is láthattuk, a signed-by után a GPG kulcsfájl elérési útját kell megadni. Ez az elérési út általában a /usr/share/keyrings/ könyvtárban található, ahová a kulcscsomag (pl. debsuryorg-archive-keyring) telepíti a kulcsot.

Ezzel a módszerrel a rendszer sokkal pontosabban tudja ellenőrizni a csomagok hitelességét, és elkerülhetőek a globális kulcskezelésből adódó biztonsági kockázatok.

Miért biztonságosabb az új módszer?

A signed-by direktíva bevezetése jelentősen növeli a rendszer biztonságát a csomagtárak hitelesítése terén. Ennek legfőbb okai a következők:

• Csökkentett támadási felület: Ha egy kulcs valamilyen oknál fogva kompromittálódik (például ellopják vagy illetéktelenek szerzik meg), az csak az adott tárolóra lesz hatással, amelyhez a kulcsot a signed-by direktívával hozzárendeltük. Ezzel szemben a régi módszerrel egy kompromittált kulccsal bármelyik megbízható tárolóból származó csomagot hamisítani lehetett.
• Explicit bizalom: A signed-by használata explicit bizalmat feltételez: a rendszergazda tudatosan, egyértelműen megbízik egy adott kulcsban egy adott tároló esetében. A régi módszerrel könnyebben előfordulhatott, hogy véletlenül bíztunk meg egy kulcsban anélkül, hogy tisztában lettünk volna a hatókörével.
• Könnyebb auditálás: A signed-by használatával sokkal könnyebben ellenőrizhető, hogy mely tárolókhoz milyen kulcsokat használunk. A bizalmi kapcsolat egyértelműen definiálva van a forráslista fájlokban. A régi módszerrel nehezebb volt nyomon követni, hogy melyik kulcs melyik tárolóhoz tartozik.
• A legkisebb jogosultság elve: Az új módszer a legkisebb jogosultság elvét követi: egy kulcs csak a minimálisan szükséges jogosultsággal rendelkezik (csak egy adott tároló csomagjainak hitelesítésére).

Összességében a signed-by direktíva egy sokkal pontosabb, biztonságosabb és átláthatóbb módszert biztosít a csomagtárak kulcsainak kezelésére, ami elengedhetetlen a rendszer integritásának megőrzéséhez.

Általános APT változás, nem tároló-specifikus

Ez egy általános tendencia az APT csomagkezelőben a Debian/Ubuntu rendszerekben a csomagtárak biztonságosabb kezelése felé. A cél az, hogy a harmadik féltől származó tárolók kulcsainak kezelése minél pontosabb és biztonságosabb legyen.

Ez azt jelenti, hogy a jövőben valószínűleg minden külső csomagtár esetében szükség lesz a signed-by direktíva használatára. Ezért érdemes átnézni a forráslistáinkat, és ellenőrizni, hogy a harmadik féltől származó tárolókhoz tartozó bejegyzések tartalmazzák-e a "signed-by=" direktívát. Ha nem, akkor érdemes mielőbb hozzáadni, elkerülve ezzel a jövőbeni problémákat és figyelmeztetéseket.

Megoldás: A signed-by direktíva hozzáadása a forráslistához

Most, hogy megértettük, miért van szükség a signed-by direktíva használatára, ideje áttérnünk a gyakorlati megvalósításra. A következőkben megnézzük, hogyan adhatjuk hozzá a signed-by= opciót a forráslistáinkhoz, hogy a frissítések a jövőben is zökkenőmentesen menjenek végbe. A folyamat nem bonyolult, és a következő lépések követésével könnyedén orvosolhatjuk a problémát.

Az érintett forráslista (.list) fájl megkeresése

A signed-by direktíva hozzáadásához először meg kell találnunk azt a forráslista fájlt, amely tartalmazza a frissíteni kívánt tároló definícióját. A forráslista fájlok tárolják az APT számára a csomagtárak elérési útjait és egyéb beállításait.

A forráslisták két helyen találhatóak meg:

• A /etc/apt/sources.list fájlban: Ez a fő forráslista fájl, amely általában a Debian rendszerek alapértelmezett tárolóit tartalmazza.
• A /etc/apt/sources.list.d/ könyvtárban: Ez a könyvtár különálló .list kiterjesztésű fájlokat tartalmaz, amelyek a harmadik féltől származó tárolók definícióit tárolják. Ez a gyakoribb megoldás a külső tárolók esetében.

Ahogy a korábbi példákban is láthattuk, a Sury.org tároló definíciója a /etc/apt/sources.list.d/php.list fájlban található. A legtöbb esetben valószínű, hogy a megfelelő fájl a /etc/apt/sources.list.d/ könyvtárban lesz, a tároló nevéhez hasonló névvel (például sury.list, php.list, nodesource.list, stb.). Mindenképpen .list kiterjesztése lesz a fájlnak.

Bár ritkább, de az is előfordulhat, hogy a tároló definíciója az /etc/apt/sources.list fájlban található. Mindez attól függ, hogyan adtuk hozzá a csomagtárat a saját listánkhoz.

A helyes GPG kulcsfájl elérési útjának azonosítása

A signed-by direktíva helyes használatához meg kell adnunk a GPG kulcsfájl pontos elérési útját. A jó hír az, hogy ezt az elérési utat általában megtaláljuk a figyelmeztető üzenetekben.

Ahogy a korábban látott képeken is szerepelt, a debsuryorg-archive-keyring csomag esetében a helyes elérési út a következő:

/usr/share/keyrings/debsuryorg-archive-keyring.gpg

Fontos, hogy a megadott elérési út egy .gpg kiterjesztésű fájlra mutasson.

A kulcsfájlt általában egy csomag telepíti (mint például a debsuryorg-archive-keyring). Ezek a csomagok a kulcsfájlt a /usr/share/keyrings/ könyvtárba helyezik. Ez a könyvtár a szabványos hely a GPG kulcsok tárolására.

A forráslista fájl helyes módosítása

Miután megtaláltuk a megfelelő forráslista fájlt és azonosítottuk a GPG kulcsfájl elérési útját, itt az ideje a fájl szerkesztésének.

Nyissuk meg a fájlt szerkesztésre: Használjuk a nano parancsot a fájl megnyitásához:

sudo nano /etc/apt/sources.list.d/php.list

Helytelen megközelítés (kerülendő!): Az egyik leggyakoribb hiba, amit elkövethetünk, ha egyszerűen hozzáadunk egy új sort a fájlhoz a signed-by direktívával. Íme egy példa, hogyan ne csináljuk (az alábbi képen látható):

Ez azért nem jó, mert a csomagtár-adatbázisban így kétszer szerepel ugyanaz a tároló definíciója: egyszer a régi, és egyszer az új módszerrel. Ez felesleges, és problémákat okozhat a frissítések során.

Helyes megközelítés: Ahelyett, hogy új sort adnánk hozzá, a meglévő sort kell módosítanunk, vagy az eredetit kikommentelnünk és egy újat létrehozni a signed-by opcióval. Íme, hogyan kell helyesen csinálni:

A képen látható, hogy az eredeti sort kikommenteltük (ezzel inaktiváltuk), és alatta szerepel az új sor a signed-by direktívával. A kommentelés helyett akár törölhetjük is az eredeti sort, kinek melyik szimpatikusabb.

A signed-by direktíva a deb szó után, szögletes zárójelben kell, hogy szerepeljen:

deb [signed-by=/elérési/út/a/kulcshoz.gpg] https://tároló.címe/ disztribúció komponens

Mentsük el a fájlt.

A módosítás ellenőrzése (apt update)

Miután elmentettük a forráslista fájlt a signed-by direktívával, ellenőriznünk kell, hogy a módosítás sikeres volt-e. Ehhez futtassuk a következő parancsot:

sudo apt-get update
sudo apt-get upgrade

A parancsokkal frissítjük a csomagtárainkat. Ha a signed-by direktívát helyesen adtuk hozzá, akkor a kulcsokkal kapcsolatos figyelmeztetéseknek nem szabad megjelenniük az apt update futása során.

Ha a signed-by direktíva hozzáadása után is továbbra is figyelmeztetéseket kapunk, akkor valami hibát követtünk el (például elgépeltük a kulcsfájl elérési útját, vagy hibás a szintaxis a forráslistában). Ebben az esetben ellenőrizzük újra a konfigurációt, és győződjünk meg róla, hogy mindent helyesen adtunk meg.

További teendők: Visszatartott csomagok kezelése és takarítás

A signed-by direktíva hozzáadása után a frissítésekkel kapcsolatos problémák ezen részét megoldottuk. Azonban előfordulhat, hogy a csomagtárak frissítése után, a sudo apt-get upgrade parancs után még mindig maradtak teendőink.

Ebben a részben a példának megfelelően átnézzük hogy a frissítés után  hogyan frissíthetjük a visszatartott csomagokat, és hogyan takaríthatjuk el a feleslegessé vált csomagokat.

Visszatartott csomagok frissítése (apt full-upgrade)

A signed-by direktíva hozzáadása és a sudo apt-get update futtatása után, a sudo apt-get upgrade parancs még mindig azt mutathatja, hogy bizonyos csomagok vissza vannak tartva (kept back) vannak. Ez azt jelenti, hogy a csomagok frissítése valamilyen okból nem történt meg.

A leggyakoribb ok, hogy a csomag frissítéséhez új függőségek telepítése, vagy meglévő csomagok eltávolítása lenne szükséges. Az apt-get upgrade parancs alapértelmezés szerint nem végez ilyen műveleteket, mert ez nagyobb változásokkal járhat a rendszerben.

A fentebb linkelt korábbi leírásban áttekintettük a --with-new-pkgs kapcsolóval történő frissítést, valamint az apt-get install <csomagnév> módszerekkel történő frissítéseket, azonban ha sok visszatartott csomag van a rendszerben, akkor ezeknek az egyszerre történő frissítéséhez a sudo apt full-upgrade (vagy a régebbi sudo apt-get dist-upgrade) parancsot kell használnunk. Ez a parancs intelligensen kezeli a függőségi problémákat, telepíti az új szükséges csomagokat, és eltávolítja a feleslegeseket.

A full-upgrade futtatása előtt nagyon fontos átnézni a javasolt változtatásokat. A parancs ki fogja listázni, hogy mely csomagokat fogja frissíteni, melyeket újonnan telepíteni, és melyeket eltávolítani. Győződjünk meg róla, hogy a változtatások elfogadhatók számunkra, mielőtt jóváhagyjuk a telepítést.

Ha minden rendben zajlik, akkor ilyesmi kimenetet láthatunk, ahol a terminál alján látható az APT folyamatjelzője is:

Felesleges csomagok eltávolítása (apt autoremove)

A sudo apt full-upgrade parancs futtatása során előfordulhat, hogy a rendszer új csomagokat telepít a függőségek kielégítése érdekében. Azonban, miután a frissítés befejeződött, ezekre a csomagokra már nem biztos, hogy szükség van.

A feleslegessé vált csomagok eltávolítására az apt autoremove parancsot használhatjuk. Ez a parancs automatikusan azonosítja azokat a csomagokat, amelyek függőségként lettek telepítve, de már nincsen rájuk szükség:

sudo apt autoremove

A parancs futtatása előtt érdemes átnézni a csomagok listáját, amelyeket az autoremove el akar távolítani. Bizonyos esetekben (például ha új kernelt telepítettünk) a régi kernel csomagok is felkerülhetnek a listára. Ha nem vagyunk biztosak abban, hogy egy csomag felesleges, inkább ne távolítsuk el.

Végső ellenőrzés

A sudo apt full-upgrade és a sudo apt autoremove parancsok futtatása után érdemes még egyszer lefuttatni a sudo apt upgrade parancsot, hogy megbizonyosodjunk arról, hogy a rendszer teljesen naprakész, és nincsenek visszatartott csomagok.

Ha a sudo apt upgrade parancs a következőt írja ki:

0 frissített, 0 újonnan telepített, 0 eltávolítandó és 0 nem frissített

akkor mindent rendben van, a rendszer teljesen naprakész.

Végül ellenőrizzük, hogy a rendszerünkön futó szolgáltatások (például a weboldalak, amelyek PHP-t használnak) megfelelően működnek-e a frissítések után.

Hibaelhárítás

Ha valamilyen okból egy rendszerfrissítés eltávolítaná a GPG kulcsunkat, például egy apt autoremove parancs egy nagyobb frissítés részeként, akkor egy curl parancs segítségével kézzel gyorsan beszerezhetjük és ismét a helyére telepíthetjük. A Sury.org csomagtár példájánál maradva az alábbi paranccsal:

curl -fsSL https://packages.sury.org/php/apt.gpg | gpg --dearmor -o /usr/share/keyrings/debsuryorg-archive-keyring.gpg

Ahol a paraméterek a következők:

• -f: fail silently (csendes hiba): ha a letöltés hibába ütközik (pl. 404), nem jelenít meg HTML hibát, és nem ír ki felesleges adatot.
• -s: silent: nem ír semmit a standard outputra (nincs státuszsor, letöltési infó, progress bar stb.).
• -S: show error: kombinálva a -s kapcsolóval, mégis megjeleníti a hibaüzenetet, ha baj van. (Hasznos, ha csak a sikeres letöltés legyen csendes.)
• -L: follow redirects: ha a szerver HTTP 301/302 átirányítást küld, akkor automatikusan követi a célig.

Összefoglalva: ez a kombináció megbízhatóan tölti le a fájlt, csendben, de nem némítja el a hibákat, és kezeli az átirányítást is.

A "| gpg --dearmor..." rész alakítja át a letöltött ASCII-armored GPG kulcsot (ami szöveg, pl. -----BEGIN PGP PUBLIC KEY BLOCK-----), egy bináris .gpg formátumra, amit az apt használni tud a "signed-by=" direktívához.

Kapcsolók:

• --dearmor: konvertálás ASCII-armored (szöveges) formátumról bináris GPG formátumra.
• -o <fájlnév>: megadja a kimeneti fájl nevét (ide kerül az eredmény).

Ügyeljünk a kimeneti fájl nevére, tehát hogy megegyezzen a korábban a list fájlban beállított útvonalon legyen, így már a következő frissítés zökkenőmentesen futhat le.

Természetesen a GPG kulcsot a saját csomagtárunknak megfelelő forráshelyről töltsük le, ez itt csak egy példa volt a Sury.org csomagtárral folytatva a sort, arra az esetre, ha egy elavult függőségek eltávolítása során a GPG kulcsunk is megsínylené a takarítást.

Itt a képen nálam is éppen ezt történt: egy nagyobb frissítés és teljes szerver újraindítás után az

apt autoremove --purge

parancs hatására egy elavult függőségi takarítás áldozatává vált a GPG kulcsom, amit az ls paranccsal ellenőriztem is, így kézi letöltés után a csomagfrissítés ismét helyreállt.

Konklúzió

Ebben a leírásban megtekintettük, hogyan kezelhetjük az APT csomagkezelő által megjelenített, a signed-by direktívával kapcsolatos figyelmeztetéseket. Megvizsgáltuk a probléma hátterét, megértettük, miért fontos a kulcsok pontos kezelése, és lépésről lépésre végighaladtunk a megoldáson.

A signed-by direktíva használata kulcsfontosságú a rendszerünk biztonsága szempontjából, hiszen expliciten összekapcsol egy tárolót egy adott kulccsal, így minimalizálva a lehetséges támadási felületet.

Ne feledjük, hogy a signed-by direktíva használata a jövőben a szabványos módszer lesz a harmadik féltől származó tárolók kezelésére az APT csomagkezelőben. Ezért javasolt minél előbb átnézni a forráslistáinkat, és elvégezni a szükséges módosításokat.

Remélem, ez a leírás segített megérteni a problémát és megtalálni a megoldást!