Nicmene jeste by to chtelo doplnit o informaci, jak je na tom v tomhle ohledu OpenVZ. Ja Linuxove capabilities vubec neznam, natoz jejich vztah k virtualizaci, takze pro me je to spanelska vesnice a nazor nekoho kovanyho by se hodil...
Nie som velmi "kovany", ale zda sa, ze OpenVZ trpi podobnymi chybami (mozno je cast uz zaplatana - neviem). Tam je tvrdenie "containers contain" priznavana featura, tak sa na to CVE prideluju. Napr. nedavne CVE-2014-3519, ktore vyzera ako dosledok oznamenia podobnej chyby v Dockeri, kde nebolo pridelene CVE.
===POZOR! Velmi zjednoduseny opis===
Ku capabilities v kratkosti - ide o rozdrobenie uzivatelskych prav na uroven skupin akcii. Vdaka tomu prakticky neexistuje "plny root", ale existuju len skupiny akcii, ktore moze uzivatel vykonavat. Root ma napriklad bezne capabilitu, ktora mu umoznuje ignorovat prava pri pristupe k suborom. Dobre je, ze mozeme pouzivat len cast capabilit, cim zmensime riziko uspesneho napadnutia systemu. Program moze mat pravo pouzivat raw sockety (napr. ping) bez prav pristupovat k lubovolnym suborom.
S "virtualizaciou" (namespaces) to ma spolocne to, ze praca s nimi, rovnako ako praca s chrootom, su tiez len capability. Konkretne praca a pristup do namespaces casto vyzaduje dost siroku capabilitu CAP_SYS_ADMIN, ktoru vyzaduju aj niektore privilegovane ioctl, praca s driverami atd. Tak je moznost fungovat so CAP_SYS_ADMIN a ludia sa dostanu na neosetrenych miestach z kontainera alebo bez toho a ludom nieco nebude fungovat.
Da sa to riesit tak, ze budeme vsade pri capabilitach kontrolovat aj to, ci dotycny nie je v namespace, z ktoreho by sa nemal dostat von. Uprava celeho kernelu na tento styl ale nie je vec 1 dna.
===/POZOR! Velmi zjednoduseny opis===