Ksplice Uptrack az Ubuntu Jaunty felhasználóknak - kernel biztonsági frissítések alkalmazása reboot nélkül

Címkék

Arról, hogy mi a Ksplice, már tavaly áprilisban írtam hosszabban. Röviden: a futó kernel patchelése (pl. biztonsági hiba miatt) menet közben úgy, hogy feleslegessé válik a rendszer újraindítása.

Hogy mi a Ksplice Uptrack? Egy, a Ksplice technológiára épülő szolgáltatás, amely egyelőre Ubuntu 9.04 "Jaunty Jackalope" felhasználók számára érhető el, és amely így kínálja magát: "A legfrissebb Ubuntu verziót használja? Mondjon búcsút az újraindításoknak!"

A "Ksplice Uptrack for Ubuntu 9.04 Jaunty" mostantól letölthető. Egy egyszerű telepítési eljárás után már használható is. A Ksplice, Inc. a Ksplice Uptrack szolgáltatást ingyen bocsátja az Ubuntu Jaunty felhasználók rendelkezésére.

A szolgáltatás használata végtelenül egyszerű, a frissítések telepítése akár grafikus felületről is elvégezhető.

Ksplice Uptrack - elérhető
Biztonsági- vagy hibajavítás érhető el a futó kernelhez

Ksplice Uptrack - telepítés folyamatban
Javítás telepítése folyamatban...

Ksplice Uptrack - telepítve
A kernel patch-elve menet közben, reboot nem szükséges

Hogyan működik a szolgáltatás?

  • Felfedeznek egy veszélyes bugot vagy biztonsági rést a Linux-ban
  • A fejlesztők és/vagy gyártók kiadnak egy javítást, ami azonban reboot-ot igényel
  • A Ksplice Inc. a Ksplice technológia felhasználásával átalakítja a hibajavítást egy olyan frissítéssé, amelynek alkalmazásakor feleslegessé válik az újraindítás
  • A felhasználó igény szerint telepítheti a "rebootless" frissítést a rendszerére
  • A felhasználó rendszere - anélkül, hogy újra kellett volna indítani - ismét naprakész és biztonságos

Jeff Arnold, a Ksplice technológia fő fejlesztője és a Ksplice Inc. elnöke egy sajtóbejelentésen elmondta, hogy az Ubuntu-ra való megjelenés után a széleskörű elérhetőség - köztük a kereskedelmi disztribúciókra is - néhány hónapon belül várható.

FAQ itt.

Hozzászólások

Nem gondoltam volna, hogy érdemes egy ilyen profilú céget létrehozni. Belegondolni is rossz, hogy mennyi munkát kell még elvégezniük, hogy esélyük legyen hosszú távon fennmaradni.

Arra tippelek, hogy először megpróbálnak "beszállítani" a nagyoknak: Canonical, Novell, RedHat, stb. Később pedig megpróbálnak majd saját disztribúciót készíteni, ahol a frissítés bináris diff, és live patch formájában töltődik le.

A technológia GPLv2-es, _bármelyik_ disztribútor befogadhatja és biztosíthatja a frissítéseket a felhasználóknak a jövőben. Csak döntés, emberi erőforrás és infrastruktúra kérdése.

Azonban a disztribútor azt is megfontolhatja, hogy melyik neki az olcsóbb. Felvesz olyat aki ért hozzá, megépíti az infrastruktúrát és üzemelteti, vagy fizet a Ksplice Inc.-nek mindezért évi x dollárt és az megcsinálja helyette. Feltehetően a Ksplice Inc. elég jól ért ehhez, hiszen a Ksplice megalkotója az elnöke a cégnek :)

--
trey @ gépház

Más is internal server errort kap, ha kulcsot akar kérni?

http://www.ksplice.com/uptrack/key itt beírom az email címemet.

Sőt, a nem kézi telepítés sem megy:

Unpacking ksplice-uptrack (from /tmp/ksplice-uptrack-1.deb) ...

There was a problem reaching the Ksplice Uptrack server.


Please check your network connection and try again.

dpkg: error processing /tmp/ksplice-uptrack-1.deb (--install):
 subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
 /tmp/ksplice-uptrack-1.deb

wow! Akkor ez hamar begyűrűzik máshová is. Bár igazán nagy haszna szerveren van. Lehet használni gui nélkül is? -> úgy fest igen.

>>: sys-admin.hu :<<

Fu wazze. Ez olyan dolog ami miett ez ember mar elgondolkodik, hogy komolyabb helyre is foltolja az Ubuntut.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Annyit elmagyaraznanak nekem hogy user szemszogbol ennek desktopra mi ertelme van?

nyilvan. pl kde megjegyzi, hogy milyen appok voltak nyitva, de azt mar nem, h pl adott konsole tabon vimben melyik file hanyadik sorara voltam pozicionalva, ott milyen regex volt hilightolva. es meg lehetne sorolni. aki hozzaszokik, h 7/24 s2ramol, annak sokszor hetekig huzodik egy reboot.

mindjárt kiderül, hogy a kde kódjában el van dugva egy virtuális gép valahol a 817623. és 817643. sor között, amit oly' egyszerű megcsinálni a qt segítségével akár 3 sorban :)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Nem a gép újraindítása a fájdalmas, hanem az, hogy mire elindítgatom az összes futó alkalmazást, a vmware-eket, megnyitom az elmentett éppen félbehagyott cikket, elindítom a zenelejátszót, stb. Ez a fájdalmas.

Ehelyett nyomok egy bekapcsológombot és még az zene is onnan folytatódik, ahol suspendeltem. Ha lenne egy ilyen kiforrott lehetőség, hogy ne kelljen újraindítani még kernelfrissítésért sem, akkor az jó lenne.

--
trey @ gépház

Save execution state-bol visszajon..hmm.. 6mp alatt ha jol szamolom. VMWare alatt meg vegulis memoria kerdese. De amugy te laptopot hasznalsz (AFAIK), s tudtommal 2/4gb ram van benn, illetve egy gyenge C2D proci. Ezen nem futthatsz annyira sok VMet (legalabbis a gep tuti nem birna el szerintem, C2Q EE-met is megszorongatja mar par VM).

A zene azert gazos ha pl otthon zenet hallgatok. Lenyomom suspend, beviszem munkaba gepet, de valami dolog van, nem kell gep. Utana felszallok valahova, gyors megkell nezni valamit rajt, akkor meg az arcomba a zene.. ez kicsit kellemetlen. :)

De amugy tenyleg kenyelmesebb, dehat most pl. hetvegen egy reboot nem faj annyira. :P Szerveren tenyleg latom sok ertelmet hogy foltozzak on-the-fly, mivel a tamadasok ket frissites kozt is beuthetnek. (Production env.-et meg nem rebootolok naponta azert)

ps.: Nezd el amugy, nekem csak WIN alatt ment mindig is suspend. Anno mukodott a P6N alaplapommal kis ideig, orultem, jo sok aramot sporoltam. Bedoglott, lecsereltek, az ujjal mar nem megy. Laptop (dell) + Ubuntu 9.04 meg annyi hogy suspend, visszajon (ha akar), aztan egy masodik suspend mar halalos. Amugy tenyleg jo dolog (lenne).

ideje megneznem egy lts verzsont a bubuntubol ugy latom
ez emberek mukodik, kiprobaltam.
install kernelpecs meg minden kb 4 perc volt.

OpenBSD 4.5/i386

Most pánikolt el a kernel de úgy, hogy még az alt+sysrq+b sem indította újra :(

futo rendszert nem a legjobb patchelgetni...
nem veletlen szoktak rebootolni, es van jo par olyan fix is, ami egy-egy struktura megvaltozasaval jar, igy ekkor is kenytelen lesz az ember rebootolni.

szvsz ez az eljaras meg nem kitesztelt annyira, hogy serverre jo legyen, igy egybol egy popularis distrot neztek ki, amin ki lehet tesztelni, mint pl az RH csinalja a fedoraval, csak itt kicsit nagyobb szorassal lehet tesztelni
___
info

> futo rendszert nem a legjobb patchelgetni...

Van ahol szükséglet:

"CGL specifies that carrier grade Linux shall provide a mechanism and framework by which a custom application can be built so that it can be upgraded by replacing symbols in its live process. Dynamic replacement of symbols allows a process to access upgraded functions or values without requiring a process restart and in many circumstances can lead to improved process availability and uptime."

"es van jo par olyan fix is, ami egy-egy struktura megvaltozasaval jar, igy ekkor is kenytelen lesz az ember rebootolni."

Ha megfelelő ember készíti a frissítést, akkor el lehet érni egész jó eredményt.

Ksplice allows system administrators to apply patches to
their operating system kernels without rebooting. Unlike
previous hot update systems, Ksplice operates at the object
code layer, which allows Ksplice to transform many tradi-
tional source code patches into hot updates with little or no
programmer involvement. In the common case that a patch
does not change the semantics of persistent data structures,
Ksplice can create a hot update without a programmer writ-
ing any new code.

Security patches are one compelling application of hot
updates. An evaluation involving all significant x86-32
Linux security patches from May 2005 to May 2008 finds
that most security patches—56 of 64—require no new code
to be performed as a Ksplice update. In other words, Ksplice
can correct 88% of the Linux kernel vulnerabilities from this
interval without the need for rebooting and without writing
any new code.

If a programmer writes a small amount of new code to
assist with the remaining patches (about 17 lines per patch,
on average), then Ksplice can apply all 64 of the security
patches from this interval without rebooting.

Ksplice: Automatic Rebootless Kernel Updates

A PDF-ben azt állítják, hogy a Linux kernellel kapcsolatban 2005 május és 2008 május közt ismertté vált, DOS sebezhetőségnél súlyosabb hibát vizsgáltak és meg tudták javítani mindegyiket anélkül, hogy reboot-ra lett volna szükség.

To evaluate Ksplice, we applied Ksplice to 64 Linux patches for kernel security vulnerabilities from May 2005 to May 2008. The 64 include all documented x86-32 Linux kernel vulnerabilities from this time interval with greater consequences than denial of service. Of the 64 patches, 56 can be applied by Ksplice without writing any new code, and the remaining patches can be applied by Ksplice if a programmer writes a small amount of new code (about 17 lines per patch, on average).

--
trey @ gépház

Ha mondjuk betörtek a gépedre és nem veszed észre, lopják az adataidat stb., akkor egy suspend frankón fenntarthatja a betámadást is, nem??

Igyexem minél többet tanulni a linuxos dolgokról, de ha most valaki illegálisan nézegetné milyen pornóim vannak, tutira nem venném észre. Egy átlag user akinek elétették mondjuk az irodában az meg pláne nem venne észre semmit, - max ha füstöl a gép, akkor pánikol egyet - viszont van olyan kényelmes, hogy mindent nyitva akar tartani.

Abban az esetben ha helyes a logikám akkor a nagy kényelemforradalom egy veszélyforrás.

Még azt is el tudom képzelni, hogy már egy patchelt biztonsági hibát kihasználó betörés folyik egy gépen hetekkel később.

--
I love the smell of flame in the morning!!! :D

Persze, éjjelre meg kapcsoljunk le minden szervert, nehogy a betámadás akkor is folyhasson, amikor alszik a rendszergazda. Vagy mi az elképzelésed mögött a lényeg?

A mai világban, amikor a malware-t már a BIOS-ba is tudják deploy-olni, azt hiszem, hogy nem a suspend a veszélyforrás és nem az a védelem alapköve, hogy gyakran rebootolunk, nehogy follyon a támadás. Illetve, a legtöbb malware - miután telepítették - az OS indítása során feléled, így nem tudom mit nyersz vele.

--
trey @ gépház

Éppen ezért mondtam, hogy az átlag user nem vesz észre, ha gépén turkálnak. Egy servert üzemeltetőnek illik észrevenni.

Az utolsó gondolatom meg az volt, hogy ha jogokat szereznek a géphez egy másnap szorgosan patchelt biztonsági hibával az még nem jelenti, hogy védve van ettől a támadástól.

szerk: üdítő gondolat, hogy szegény hacker is folytathatja a munkát, következő elindításkor :DDDDD
--
I love the smell of flame in the morning!!! :D

Még mindig nem értem, hogy ennek mi köze van a suspend-hez.

"egy suspend frankón fenntarthatja a betámadást is, nem??"

Ez alatt mit értesz? A suspend ideje alatt nincsenek élő hálózati kapcsolatok. Mi tartja fenn a "betámadást"? Vagy miben másabb a suspend-ből resume, vagy egy reboot, amikor a reboot után a malware ismét aktív, keresi a c&c szervert, irc csatornát, stb.

--
trey @ gépház

A suspend típusától függ (suspend to RAM, suspend to disk).

De ez történik reboot után is. A rendszer a boot és a desktop felület indítása során a merevlemezre mentett adatokat visszatölti a memóriába és minden megy tovább... Gondolom el tudod képzelni, hogy milyen nehéz egy olyat csinálni, hogy induljon el XY valami, ha belépsz a desktop környezetedbe, shell-t kapsz, stb. Ha semmit nem értesz hozzá - és ez volt a feltételezés - fogalmad sem lesz, hogy mi és honnan indult el.

--
trey @ gépház

Akkor most feleslegesen tűzték ki a 10mp-es boot időt?

Mennyire fog együttműködni vajon az egyéb frissítésekkel? Ubuntunál nem csak kernel frissítéskor kellett rebootolni eddig.

Miért is? És mi köze ennek a Gentoo-hoz? Ha Ubuntut akartál írni, akkor is, van ahol fontos a boot sebesség. Pl. a szomszédomban is, van egy Ubuntu, ők minden nap használják a gépet pár órára, majd kikapcsolják. De ha sürgősen kell az infó valamiért (pl. mert épp indulnának kirándulni, de jön felfele az idő) akkor jól esik a gyors boot.

És ugye a Ksplice, Inc nem gonosz és sosem lesz az? ;-)
---
;-(

Két kérdés jutott eszembe:

- Miért talált a legújabb ubuntu kernelben 6 hibát, azt miért nem javították a fejlesztők?
- Most hogy így javítva lett ez a pár hiba, ha a fejlesztők kiadnak csomagfrissítést, akkor azt telepíteni kell, vagy holdolni kell a kernel csomagot?

A Ksplice oldalán a FAQ-t meg az owerviewt megnéztem, de ott nincsenek erre válaszok.

"- Miért talált a legújabb ubuntu kernelben 6 hibát, azt miért nem javították a fejlesztők?"

Megnéztem az első bugot:

"This bug was fixed in the package linux - 2.6.28-13.44" "jaunty-proposed"

Megnéztem egy másikat:

"This bug was fixed in the package linux - 2.6.28-13.44" "jaunty-proposed"

A "proposed" (más néven 'pre-released updates') be van nálad állítva?

"Most hogy így javítva lett ez a pár hiba, ha a fejlesztők kiadnak csomagfrissítést, akkor azt telepíteni kell, vagy holdolni kell a kernel csomagot?"

Miért kellene hold-ra tenni? Feltelepíted az új kernelt, majd NEM reboot-olsz. Amikor legközelebb reboot-olsz, majd azt indítod. Addig meg "véd" a probléma ellen a Ksplice frissítés. Amikor az újabb kernellel indítod a rendszer, akkor ismét lenyomod az Ksplice-ban az ellenőrzést és ahhoz képest megvizsgálja a rendszer, hogy mi változott. Szerintem ez működik.

--
trey @ gépház

A Proposed tároló be van állítva:

$ uname -a
Linux spymorass 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:57:31 UTC 2009 i686 GNU/Linux

Vagyis amit linkeltél kernelt az fut, és ahhoz találta a 6 frissítést.

A második rész a végülis oké, mondjuk ezt a Ksplicet úgyis csak kíváncsiságból pakoltam fel. Nálam nem probléma a restart.