Fedora bude odstraňovat balíčky se špatnými bezpečnostními praktikami

Fedora bude odstraňovat balíčky se špatnými bezpečnostními praktikami. FESCo, technická komise Fedory, schválila návrh, podle kterého by se měly balíčky, na které je už déle než 6 měsíců nahlášená bezpečnostní chyba na úrovni CRITICAL a IMPORTANT nebo i nižší, vyřadit z distribuce. Správci daných balíčků budou pravidelně upozorňováni a budou mít 8 týdnů na nápravu. Pokud chyby neodstraní, balíček bude vyřazený z repozitářů, aby se už nedostal do dalších verzí Fedory.

3.9.2018 04:00 | Ladislav Hagara | Komunita

Komentáře

[micno]

to odstrania fedoru ?

[smazáno]

prvni co jsem si rikal, tak ze prvne odstrani ten flatpak co vsude tlaci :), pak systemd ... :)

[RB]

Flatpak a systemd nemůžou za tvůj posraný život

[smazáno]

To zrovna u me z principu nemuze.

Ale obecne se i to muze stat, kdyz ti nekdo diky deravymu flatpaku vykrade ucty a ukradne privatni klice ;).

[RB]

No, já jenom, že máš potřebu se k nim vyjadřovat prakticky pod každou zprávičkou o nich.

Jinak pokud jsou Flatpak a systemd tak děravé, tak nebude problém tam nějaké pěkné CVE najít, dát tomu cool jméno a stát se slavným

Mimochodem i kdyby Flatpak děravý byl, tak nevím, jak mě v tomto ohledu ochrání tradiční způsob distribuce softwaru - balíčky. Když si nainstaluju DEB balíček do systému, tak nemám ani pokus o izolaci.

[smazáno]

Prijde mi ferove informovat jak se veci skutecne maji.

Flatpak se taky o zadnou izolaci nesnazi, je to o ale o dost horsi, protoze se uzivatelum tvrdi ze ano. Skoro 100% balicku z flathubu ma pristup k celemu tvemu filesystemu, vcetne rw do tveho home a pristup k siti. Navic je to plny verejne znamych chyb, protoze se neupdatuje, i podle CVE si muzes najit chyby, ktere ve flatpaku (resp flathubu) stale jsou, vcetne code execution.

A mimochodem, ne vsechny verejne zname chyby maji CVE. Navic, kdyz nekdo reague na oznameni bezpecnostni chyby takto, tak neco jako responsible disclosure vuci tomu projektu uz nemuzes cekat.

[pavele]

Pořád nechápu, proč se místo rpm balíčků neinstalují balíčky s flatpakem.

Holý systém - pouze kostra.

Zbytek flatpaky místo rpm balíčků pod správou lidí dané linuxové distribuce.

Tím by se řešila centrální správa, bezpečnost a prakticky neomezená tvorba jakékoliv verze programu.

Omezeno pouze na lidské zdroje.

[smazáno]

Zbytek flatpaky místo rpm balíčků pod správou lidí dané linuxové distribuce.

To by byla urcite lepsi situace nez ted, kdy se o ty flatpak balicky nikdo poradne nestara a opravdu v nich jsou zname bezpecnostni chyby. A kazdeho pul roku jim tam pribude nova sada runtimes ..

Ale zalozit runtimes na existujici distribuci, misto aby si to bastlili samy, by byl velky krok kupredu. Svym zpusobem by dohonili snap a docker :).

Tím by se řešila centrální správa, bezpečnost a prakticky neomezená tvorba jakékoliv verze programu.

Bezpecnost urcite ne, protoze ve flatpaku uz dosli k tomu, ze ty flatpak balicky proste potrebuji pristup na /, k dbus socketum, atd.

Jinak ano.

Navic ti tohle ale zavede problemy s integraci (zkus si treba ted ve flatpaku takovou blbost jako zmenit velikost "interface fontu" - to funguje pouze v gnome aplikacich ve flatpaku, v KDE aplikacich ne, bez flatpaku to samozrejme funguje vsude), tohle prece nemuzes dorucit uzivatelum.

Podobny problem je i s nastavenim temat - pokud pouzivas adwaita(-dark) nebo highcontrast (a mozna par dalsich) tak cajk, dokonce ta zmena funguje i hezky "online" pres dbus, ale pokud pouzivas jine tema, tak mas smulu. Dalsi priklad je treba CJK, korporatni CA certifikaty, ..

[Abi]

Témata vzhledu jsou takový fetiš Linuxu. Popravdě to nikdy pořádně nefungovalo a nebude fungovat. Autor aplikace navrhne téma s nějakým vzhledem a uživatel si na to potom aplikuje téma, které to rozbije... To je taky jediný důvod, proč Flatpak a Snap neumožňují aplikovat systémové téma, protože nikdo nikdy není schopný garantovat, jak ta aplikace bude s tím tématem vypadat. Přimountovat adresář se systémovými tématy je ten nejmenší technický problém. Jinak zakládat runtime na existující distribuci? Stačí se podívat třeba na universe v Ubuntu... Nemám problém, když někdo vyžaduje vysoké bezpečnostní standardy po Flatpaku, ale je dobré se podívat na alternativu. Linuxové distribuce, zvláště ty komunitní, tedy žádný zázrak nejsou, když se považuje za pokrokové, že Fedora začne vyřazovat balíčky z repozitářů, když je v nich kritická bezpečnostní chyba "jenom" 6 měsíců. Navíc Flatpak je teď alternativa spíše k nejrůznějším bundlům třetích stran v samostatných balíčcích nebo PPA apod. A to je naprostý etalon bezpečnosti, že?

[smazáno]

Témata vzhledu jsou takový fetiš Linuxu.

A windows (viz napr tady nebo tady, tady, atd) a androidu ..

Popravdě to nikdy pořádně nefungovalo a nebude fungovat.

Bez flatpaku nemam problem. Uz v Ubuntu 14.04, kdyz si prenastavim tema, tak se zmena aplikuje zaroven na Qt i Gtk aplikace.

To je taky jediný důvod, proč Flatpak a Snap neumožňují aplikovat systémové téma, protože nikdo nikdy není schopný garantovat, jak ta aplikace bude s tím tématem vypadat.

Toto neni pravda, temata doporucuji lidi od flatpaku vsechny "prebalit" (kazdych 6 mesicu) pro flatpak. A jak pisu vyse, pro adwaita, adwaita-dark a high contrast to funguje jak kdyby to ani ve flatpaku nebylo (povidaji si pres dbus socket, to je udelany hezky).

Přimountovat adresář se systémovými tématy je ten nejmenší technický problém.

Samozrejme. Kdyby to bylo tak jednoduche, tak uz to tak davno funguje (viz napr. export fontu do /run/host/fonts, ani to ale neni 100%). Problem je ze gnome rozbiji kazdy pul rok ABI/API.

Ale hlavne, integraci snap i flatpak bohuzel rozbiji skoro kompletne, nejedna se pouze o temata.

Navíc Flatpak je teď alternativa spíše k nejrůznějším bundlům třetích stran v samostatných balíčcích nebo PPA apod. A to je naprostý etalon bezpečnosti, že?

Vzhledem k tomu ze tyto balicky zavisi na knihovnach v distru, tak tam nenastava ten problem, ktery zavidi flatpak a snap, kdy jde uspesne zneuzivat zname bezpecnostni chyby v zavislostech. Navic tam ani neni ten "pocit sandboxu" zatimco ale ve skutecnosti aplikace muze vsude.

Ja chapu ceho se snazi tyto projekty docilit, a bych rad kdyby se jim to povedlo, ale nesmi pritom zavest radu novych problemu a zavest kriticke bezpecnosti chyby (a tak nejak se o tom zapomenout zminit) - to si pak zaslouzi sepsout pod kazdou zpravickou.

[smazáno]

Mimochodem, tohle neni nic noveho, na vsechny tyto problemy uz (nejen ja) upozornuji od roku 2015, kdy se to nejak zacalo rozjizdet. A to jsem teda jeste naivne veril, ze ten sandbox bude fungovat.

[Abi]

Tak si to shrňme:

Tvrdíš, že se v aplikacích nebo runtimech dají najít zneužitelné chyby. Já s tím souhlasím. Pro toho, kdo dělá v tomto odvětví, to opravdu není šokující zjištění. A znovu opakuji, podívejme se pro srovnání na distribuce: universe, který je v Ubuntu by default povolený, nemá žádnou podporu a jsou v něm stovky otevřených bezpečnostních chyb, na které se nikdo nikdy nepodíval, protože většina balíčků nemá správce. Ano, Ubuntu je v tomto ten horší případ, ale máslo na hlavě mají všechny distribuce včetně těch komerčních, které mají bezpečnostní týmy (např. Red Hat garantuje opravu kritické bezpečností chyby do 5 pracovních dní, ale pro ty nekritické už žádná záruka není). Ano, správce aplikace ve Flatpaku to má těžší v tom, že to, co si bundluje, si musí hlídat, správce v distribuci má toto jednodušší, protože většina distribucí bundlování neumožňuje a musí tak záviset na balíčcích ostatních. Ale to je dvojsečné, protože pokud třeba můj balíček v Ubuntu závisí na neudržovaných balíčcích v universe, tak přejímám i jejich bezpečnostní chyby a pravidla distribuce mi neumožňují si raději přibundlovat opravené verze. Flatpak umožňuje.

Dál tvrdíš, že celá řada aplikací ve Flatpaku má povolený přístup k hostovi. Logicky, když uživatel z té aplikace chce přístup ke svým datům a ta aplikace neumí pracovat s portálem, musí jí dát "bianco" přístup. To ale dává úplně každé aplikaci nainstalované přes balíček. Na rozdíl od toho balíčku ale má uživatel jednoduchý způsob, jak to změnit, pokud aplikaci nevěří. U Flatpaku a snapu je to o změně jedné (nebo více) hodnot v konfiguraci sandboxu dané aplikace. U balíčků to je o netriviálním hraní se SELinuxem a AppArmorem apod. Opět nevím, v čem jsou Flatpak a snap v tomto horší než normální balíčky.

Pocit "sandboxu" máš možná ty. Nepřijde mi, že ty projekty se snaží tvořit vytvářet dojem, že aplikace v nich zabalené běží super bezpečně. Na Flatpak.org není mezi výhodami Flatpaku o bezpečnosti nic, na snapcraft.io mají: "Not only are snaps kept separate, their data is kept separate too. Snaps communicate with each other only in ways that you approve." Což je pravda. Pořád to je uživatel, který si může nastavit, jestli má aplikace přístup k jeho datům nebo ne. Na rozdíl od balíčků a instalace aplikací do systému, obě technologie umožňují běh aplikace izolovaně, že ho nevynucují, je fakt, ale nejsou v tom o nich horší než tradiční balíčky. Naopak obrovská jejich výhoda je, že nevyžadují roota a neumožňují spouštět libovolný skript při instalaci (nad hostem). U RPM a DEB je autor balíčku schopný smazat uživatelovi celý disk už během instalace.

K těm Windows a Androidu. Odkazuješ pouze na změny v systémového UI a možná základních aplikací. Např. Android umožňuje úpravu témat, ale z pozice autora aplikace. Opravdu jsem si nevšiml, že by na Androidu bylo běžné systémově vnucovat témata aplikacím. Realita je taková, že na ostatních systémech minimum uživatelů používá jiná témata a autor aplikace je ten, kdo určuje, jak její UI bude ve finále vypadat. Proto říkám, že toto je takový fetiš Linuxu než něco běžného.

Nemám nic proti tomu, když někdo upozorňuje na nedostatky nějakých technologií, ale popravdě ten tvůj přístup k Flatpaku a snapu mi přijde hooodně zaujatý. Kdyby ti šlo o bezpečnost uživatelů Linuxu, tak bys měl psát o tom, že si mají dávat pozor i na to, jaký balíček z distribuce si instalují, protože to tam taky není úplně sluníčkové, a že se mají vyvarovat instalace balíčků z repozitářů třetích stran jako PPA, protože tam nejsou vůbec žádné garance podpory a autorovi takového random PPA uživatel dává de facto root přístup ke svému stroji atd., protože Flatpak a snap jsou alternativy právě k tomuto (ne k takovému security-focused QubesOS, kde každá aplikace běží ve vlastní VM), ale tebe zjevně tankuje jenom ten Flatpak a snap.

[smazáno]

http://docs.flatpak.org/en/latest/sandbox-permissions.html prvni veta

Tohle snad kazdemu bude stacit aby pochopil ze si z Red Hatu a jen siris bludy.

[smazáno]

Na klasicky distra (berme debian) nemam v ruce exploity na code execution, ty jo? Muzeme zverejnovat jeden po druhym za ty moje na flatpak.

[Abi]

Ano, u Debianu asi nebude něco takového jednoduché najít. Proto ho taky používám, ale proč se omezuješ na něj? Co je na Ubuntu neklasického? Že je odvozená distribuce? Těch je dnes většina. Je nejpopulárnější, staví na něm řada dalších distribucí. Mrkni třeba do balíčků universe 16.04, tam určitě nějaký code execution najdeš A to se pořád bavíme o distribučním repu. PPA jsou mnohem, mnohem větší bezpečnostní průser než Flatpak. Ale ty tě zjevně netankují, protože ty máš osobní problém s Flatpakem a očividně i Red Hatem.

[smazáno]

Byl bych hrozne rad, kdyby flatpak a snap (ten vypada o neco lip) fungovali tak jak slibuji.

[Abi]

To, že mají něco za cíl, neznamená, že ho dosáhli a že to tvrdí.

Jinak paranoia není pěkná věc. To, že s tebou někdo nesouhlasí, ještě neznamená, že je z Red Hatu.

[smazáno]

A posledni vec - k tomu jak ses zasekl na tematech, pokud by nebyla moznost zmenit tem vubec, tak bych to bral. Pokud to jde ale funguje jen nekde, tak to je trapne amaterske.

Ale nejde o temata, jde o a11y, cjk atd !

[smazáno]

Mimochodem, o tohle se snazi snap (a rekl bych, ze jsou ted dal nez Red Hat; s tou integraci to je ale hodne spatny, videl jsem stiznosti ze jim tam nefunguje CJK) a maji tam ten stejny problem se zavislostma. Existuji zname bezpecnostni chyby (i s prirazenym CVE) opravene v Ubuntu baliccich, ale snap vyuzivajici ten balicek neni (automaticky) rebuildovany.

Ale ve snapu jsem nasel jen DoS (resp. podle DSA "denial of service or potentially the execution of arbitrary code"), vylozene code execution se mi narozdil od flatpaku nepovedlo. Ale zas tolik casu jsem tim nestravil, u flatpaku je to fakt pro script kiddies.

[Meresjef]

Na jednu stranu hezké. Na druhou stranu by člověk čekal, že nějaké takové procesy uplatňují už dávno.