Snap me trochu zklamalo. Jestli ze je nutnost pribalit vsechny zavislosti, pak je to na nic. Na linuxu vseobecne mam rad ze nezabira moc mista ani po instalaci vsech potrebnych baliku. Proste pri prvnich cca 10-ti instalacich nejakeho SW mam drtivou vetsinu zavislosti resp. knihoven stazenych a pak mi system "nebobtna". Dale jak je zmineno v clanku, tak opravy chyb jsou v drtive vetsine rychle opraveny a aktualizovany. Timto se dostavame k hruze kdy kazdy vyvojar si bude aktualizovat vse sam v balicku. Vim ze udrzovat balicek/SW tak aby fungoval s aktualni verzi nejake zavislosti je slozite a casove narocne, ale toto si myslim ze bude jeste vice narocne aby vyvojar nevydal kriticke opravy sveho SW jednou za pul roku, tak se mi celkove aji mozna nelibi vubec tato moznost i kdyz jeji prinos vidim a chapu. Bojim se toho ze se cely tento system kvuli lenosti vyvojaru zvrhne a nakonec kazdy balicek bude mit vsechny zavislosti v sobe.
A co říkáte na model:
Jádro systému ze skládá ze standardních balíčky deb/rpm a k tomu mám nejnovější Firefox a nejnovější LibreOffice ze snapu/flatpacku?
Když náhodou budu mít děravou verzi šifrovací knihovny a někdo se mi nabourá do počítače přes Firefox (a budu používat zobrazovací server waylandu nebo mir), tak mi shodí prohlížeč, nic víc. Není to tak?
LibreOffice a Firefox pocházejí z Linuxového světa a neměli by ho házet přes palubu s "nám se nechce testovat pro všechny distribuce". Stejně to za ně dělají lidi z Debianu a ostatních distribucí.
Vzhledem k tomu, že skrz Firefox zadávám číslo platební karty, tak opravdu nebudu spokojenější když mi nespadne celý systém zatímco mi budou vykrádat bankovní účet.
Je tomu už pár let, co mně učili instalovat provozní aplikaci na server, případně vývojové prostředí k sobě na počítač a to tímto způsobem:
1. Instalovat programovací jazyk
2. Instalovat aplikační server
3. Instalovat framework, CMS
V tom konkrétním případě se jednalo o python, zope, plone. Myslím si, že to je relativně dobrá praktika, která zajistí, že mám nainstalované všude totéž, ale že je jednodušší nainstalovat si jeden snap/flatpack než to dělat všechno postupně. Vidím hvězdu jasnou, ... chtěl jsem říct jasnou výhodu, zjednodušení práce. Balíčkovací systém je fajn, ale tohle je prostě situace, kdy dávám přednost tomu, jej nepoužívat.
To je ale akce na jeden řádek v shellu. Dokonce i s kontrolou, že pokud se některý z nich zasekne, instalace dalšího se neprovede. Viz. man dnf.
Fakt má cenu kvůli tomu přejít ne balíčkovací systém s virtualizací a řešit, proč to nefunguje, když dva balíčky ze tří budou mít jinou verzi některé knihovny, než ten třetí?
A a s tim prohlizecem tam budes mit jeste dalsich 487 aplikaci, kazdou s jinou verzi ty knihovny a 80% autoru zadnou aktualizaci nevyda. Takze misto abys aktualizoval jednu knihovnu a tim zabezpecil vsechny appky ktery ji pouzivaj, budes mit 400 deravych appek.
Presne jako ve widlich ...
Běž se zeptat chlapců od PC-BSD, jak pochodili s PBI. Upřímně, nic horšího jsem léta, ale skutečně léta neviděl. Teď tady vychází seriál o pfSense. Tam tenhle evoluční omyl zatáhli s verzí 2.2 a s verzí 2.3 po neskutečném množství stížností uživatelů a správců balíčků zase s úlevou ve verzi 2.3 opustili.
Ono je to ale casto obracene. Vyvojar by rad pouzil nejnovejsi verzi knihovny, protoze ma nejake nove zajimave vlastnosti a ma opravene nejake neprijemne bugy. Protoze ty chyby nesouvisi s bezpecnosti, tak je distribuce odmita opravit a dalsich x let bude potreba podporovat build aplikace s nejakou archaickou zabugovanou verzi knihovny XY.
Problem vetsiny soucasnych distribuci je ze se aplikuji stejna pravidla na vsechny baliky. Chapu ze je rozumne pouzivat 5 let stejnou verzi kernelu, gcc anebo glibc. Co ale nechapu je, proc nemuzu pouzivat v editoru doplnovani textu, protoze distribuce pouziva zebugovanou verzi knihovny XY a odmita s tim cokoliv udelat. Stejne tak chapu uzivatele ze jim vadi 5 let stara verze OpenOffice, kdyz nejnovesti verze je mnohem lepsi. Tohle neni "stabilita" ale "stupidita".
Mě třeba vyhovuje Debian testing a LibreOffice mám aktuální. Stable jednoduše znamená neměnná včetně nedostatků. V testing se zase může s každým update něco pokazit a potrvá to týden než se to spraví.
Chápu, že uživatel by uvítal stable systém a up-to-date vybrané aplikace, ale spravovat distribuci je podle mě nevděčná práce a znamenalo by to víc nevděčné práce pokud by to vůbec šlo. Nešlo by to převážně proto, že aplikace trvají na konkrétních verzích knihoven i když by jim stačila verze libovolná. Myšlenka by to ovšem mohla být užitečná a když seženete dost lidí můžete si nějakou distribuci forknout. Mrvit kvůli tomu distribuce všechny je zrovnatak stupidita.
Snappy (správce balíčků) v Ubuntu umožňuje používat pouze centrální repozitář od Canonicalu.
Tuhle vyšlo na blogu Dustina Kirklanda howto, jak hostovat vlastní "snap store", zatím jsem to nezkoumal do podrobna:
http://blog.dustinkirkland.com/2016/06/howto-host-your-own-snap-store.html
neni nahodou duvodem proc vubec neco takoveho vznika to, ze linux (kernel a userspace) se pri updatech meni cloveku pod rukama, nic se poradne netestuje, zpetna kompatibilita knihoven ... se moc neresi, veci ktere fungovaly najednou z neznameho duvodu nejedou, neni stabilni API/ABI atd ...
Pár poznámek:
* aplikace ve Flatpaku JSOU od sebe striktně odděleny. Taky neplatí, že si můžou vyzobávat, co kde jinde po systému je zabaleno ve Flatpaku. Můžou používat pouze runtimy, které se celé připojí read-only do sandboxu a aplikace je může používat. Existuje tam tedy pouze jedna závislost, na konkrétním runtimu. Ten může být využívaný více aplikacemi. Aplikace si ale nevybírá, co v systému je a co by se jí hodilo. Ta si řekne o konkrétní runtime, který na systému nijak nezávisí.
* nevím, jestli Flatpak bude používat SELinux, mám pocit, že se od toho plánu zcela upustilo kvůli portovatelnosti. Např. snapy (které používají AppArmor) s tím mají momentálně docela problémy. Na ne-Ubuntu distribucích je sandboxing zcela vypnutý, na Fedoře to dokonce vyžaduje vypnout SELinux.
* ty runtimy tam nejsou primárně kvůli úspoře místa, ale kvůli bezpečnosti. Jsou v ní umístěné nejpoužívanější a také na bezpečnost nejcitlivější komponenty. Předpokládá se, že o runtimy se budou starat větší upstreamové projekty nebo distribuce, které si bezpečnostní aktualizace lépe ohlídají.
Na Linuxu vám jakákoliv aplikace může poslouchat X11 events, takže piškvorky můžou vidět co píšete do terminálu přihlášeného pod rootem. Podobně každá aplikace může posílat X11 events jakékoliv jiné, takže piškvorky můžou do terminálu přihlášeného pod rootem podvrhnout jakýkoliv vstup z klávesnice včetně "rm -rf --no-preserve-root /".
Snap ani Flatpack popsaný problém podle všeho neřeší: X11 is inherently insecure, which makes it impossible to sandbox applications that are using it.
http://flatpak.org/press/2016-06-21-flatpak-released.html
The security minded will observe that X11 is not in fact a secure protocol. A number of system abuses are possible when we hand an application this permission.
http://blog.labix.org/2016/04/22/snappy-interfaces
Ale nenechte se zmást nějakými technickými detaily. Za vás je zjevně jediný povolený komentář "Tux rulez!", diskuse je tu proto abyste si v ní mohl leštit tučňáka, a cokoliv jiného je trolling :D
Já už na svém pracovním a soukromém notebooku používám Wayland, takže pro mě to řeší. Myslím, že je dobře, že oba projekty jasně říkají, že pokud uživatelé používají X11, nejsou ty aplikace sandboxované. Každý už si může rozmyslet, jestli to je pro něj přijatelné riziko a bude dál používat X11, nebo přejde na Wayland. Poslední verze GNOME už běží na Waylandu pěkně. Možnost tady je.
Z pohledu klienta (aplikace) je rozdíl mezi Mirem a Waylandem malý. Navíc to pokryjí frameworky jako Qt nebo GTK. Co se týče Snap vs. Flatpak, tak tam je nejzásadnější, aby bylo jednotné API, přes které bude aplikace komunikovat se zbytkem systému (požádá si o přístup k souborům, webkameře,...). Před pár týdny lidi, kteří u nás pracují na Flatpaku, pozvali lidi, kteří pracují v Canonicalu na snapech, na schůzku, kde se dohodnou na jednotném API, protože by bylo dost neštastné, aby musely aplikace podporovat dvě různá rozhraní.
Nevím přesně, na čem se dohodli, ale doufám, že v tomto ta spolupráce bude pokračovat. Samotné zabalení pro oba formáty už je potom spíš prkotina.
Takže o User Interface Privilege Isolation jste fakt ani neslyšel? To je taková ta součást Windows Integrity Mechanism, která brání aplikaci typu piškvorek v podvržení window messages například do okna PowerShellu. Mimochodem je to technologie, kterou mají desktopové Windows minimálně deset let. Nemluvě o UWP, kde jsou věci ještě trochu jinak.
https://msdn.microsoft.com/en-us/library/bb625957.aspx
https://msdn.microsoft.com/en-us/library/bb625963.aspx
luliku, mluvis o ty picovine, kterou ma kazdej clovek kterej neche skoncit u chocholouska vypnutou? Mimochodem, procpak mi na uzivatele !!!s USER!!!! accountama blejou widle pozadavek na admin acc kdyz se nainstaluje ta vase aktualizacni sracka na odstranovani nezadaneho SW? Nebo mi vysvelli, jakej zamer pojal M$ tim, ze na terminal serveru vyskakuje na usery ze sou novy aktualizace, pripadne pozadavek na restart? Pricemz tak jako tak ani jedno ani druhy udelat nemuzou?
Jinak mluvis pocitam o ty technologii, ktera umoznuje podvrhnout widlim libovolnou systemovou knihovnu a dat do ni naprosto cokoli? nj, zkontrolvoat aspon crc jestli se odminula nezmenilo, to je hitech pristiho milenia ...
Ne, mluvím o něčem jiném a linkoval jsem to. Jestli neumíte číst, neumíte anglicky nebo je na vás dokumentace TLDR, tak je to váš problém.
Ad procpak mi na uzivatele !!!s USER!!!! accountama blejou widle pozadavek na admin acc kdyz se nainstaluje ta vase aktualizacni sracka na odstranovani nezadaneho SW - user má user account, tak už to bývá. Pokud jde o neprivilegovaný account, a ten nástroj je Maliciou5 S0ftware R3moval T00l, tak ten prostě potřebuje admina, protože odstraňuje například kernelové rootkity, které pod uživatelem jaksi odstranit nelze.
Ad jakej zamer pojal M$ tim, ze na terminal serveru vyskakuje na usery ze sou novy aktualizace, pripadne pozadavek na restart? Pricemz tak jako tak ani jedno ani druhy udelat nemůžou - instalovat aktualizace defaultně můžou, na restart by default oprávnění nemají (a také je ten button neaktivní). Pokud chcete aby neprivilegovaní uživatelé nedostávali notifikace o updatech, je na to v GPO položka A110w non-administrators to r3ceive update n0tification5. Ovšem tohle všechno by měl znát i admin-samouk. Nechápu jak jste se mohl naučit hjkl vi, bash a regexy, když se neumíte naučit takové triviality.
Ad mluvis pocitam o ty technologii, ktera umoznuje podvrhnout widlim libovolnou systemovou knihovnu a dat do ni naprosto cokoli - asi ne. Která konkrétní technologie to má být? BTW na Linuxu nemůžete se správnými permissions zaměnit binárku nebo knihovnu? Aha.
Ad poznate jediny program mimo UAC, ktory tieto veci vyuziva - komponenty Windows (wininit, winlogon, svchost, spooler, virtual machine management, session manager, csrss, task scheduler, fulltext indexer, desktop window manager, konzole atd.), Windows Explorer, Internet Explorer, Google Chrome, Adobe Reader, Steam a další.
Ad Takuto zhovadilost spravite i v iXkach a ani na to netreba dalsi nalepeny layer - konkrétně?
Ad Problem ale treba riesit z pohladu programu, ktory ma tie vstupy dostavat - Windows to řeší z pohledu programu, který ty podvržené vstupy naopak nemá dostávat.
Ehm... Nie. Skoro do kazdeho z menovaneho som uz emulovane vstupy posielal, ci uz cez autohotkey, python alebo dementny script vo visualbasicu.
X11 ma u kazdeho eventu flag oznacujuci, ci bol poslany pomocou SendEvent. Programom sa odporuca tento flag ignorovat, ale taky dialog s heslom alebo gksudo ho typicky nebere. Druha moznost, pouzivana hlavne pri zadavani hesiel, je spravit grab na celu klavesnicu.
> Windows to řeší z pohledu programu, který ty podvržené vstupy naopak nemá dostávat.
Vdaka com sice nemozem podvrnutym vstupom instalovat driver, ale celkom pokojne si z Chromu copy-pastnem hesla :)
Na druhej strane, ked uz mam k PC takyto pristup, ziskavat info cez sendkeys je dosti postavene na hlavu.
Tak si zkuste spustit například cmd.exe pod administrátorem, a posílejte mu keystrokes z aplikace běžící pod neprivilegovaným účtem. Podle dokumentace vám volání projde, ale message nebude doručena. To jsem popisoval v příkladu s piškrovkami a terminálem přihlášeným pod rootem; na Linuxu je zjevně situace jiná.
Ad nemozem podvrnutym vstupom instalovat driver, ale celkom pokojne si z Chromu copy-pastnem hesla - záleží integrity mode. Browser většinou běží v low integrity mode, takže z něj můžete číst, ale on nemůže posílat messages (plus má pár dalších omezení například na FS).
Ad ked uz mam k PC takyto pristup, ziskavat info cez sendkeys je dosti postavene na hlavu - pokud se na to díváte "tradičně" způsobem že aplikace běžící v kontextu uživatele může všechno co může uživatel, tak ano. Problém je v tom, že aplikací existuje spousta, a těžko zabránit tomu aby piškvorky dělaly neplechu. Proto je potřeba nějaký druh sandboxingu, stejně jako třeba na mobilech. To řeší například UWP. U Win32 aplikací je to ale problém, protože ty byly napsány s tím starším pohledem na věc. Proto se zavádějí workaroundy jako integrity level, secure desktop (to jsou typicky UAC messages) atd. Navíc existují například nástroje pro alternativní vstup textu (řekněme když si zlomíte obě ruce a píšete na klávesnici brčkem), které mají výjimku (musí být uvedena v manifestu, vyžaduje digitální podpis kódu).
Ad X11 ma u kazdeho eventu flag oznacujuci, ci bol poslany pomocou SendEvent. Programom sa odporuca tento flag ignorovat, ale taky dialog s heslom alebo gksudo ho typicky nebere. Druha moznost, pouzivana hlavne pri zadavani hesiel, je spravit grab na celu klavesnicu - grab na klávesnici je dost špatná technika. Ve Windows můžete vyjma integrity levels také vytvořit nový izolovaný desktop (což můžete vidět na UAC prompts), nebo aplikaci vzít DESKTOP_HOOKCONTROL, takže jí nikdo nic nepodvrhne.
> Tak si zkuste spustit například cmd.exe pod administrátorem, a posílejte mu keystrokes z aplikace běžící pod neprivilegovaným účtem.
http://pasteboard.co/22CjZP8x.png
> záleží integrity mode. Browser většinou běží v low integrity mode, takže z něj můžete číst, ale on nemůže posílat messages (plus má pár dalších omezení například na FS).
ahoj. Toto slovo som Vam sem pripisal hore uvedenym skriptom :)
> to řeší například UWP. U Win32 aplikací je to ale problém, protože ty byly napsány s tím starším pohledem na věc.
A prave v Linuxe toto problem nieje. (s)chroot mame uz strasne dlho a sandboxovat X11 cez xpra alebo nieco podobne je sice technologicky trochu prekomplikovane, ale z pohladu uzivatela neviditelne.
S Waylandom sa to da jednoduchsie, ale za cenu restrikcii, ktore uzivatelia imho nebudu ochotny akceptovat.
Ad ahoj. Toto slovo som Vam sem pripisal hore uvedenym skriptom - a já si právě na Win10 x64 zkusil, že SendMessage projde, ale messages nejsou doručeny. Mohl bych taky dát screenshot, ale uvidíte jen kód a cm.exe, což je dost nuda. Nevím proč to u vás jde. Nemáte náhodou vypnuté UAC?
Ad (s)chroot mame uz strasne dlho a sandboxovat X11 cez xpra alebo nieco podobne je sice technologicky trochu prekomplikovane, ale z pohladu uzivatela neviditelne - chroot neřeší X11. A používat lokálně X11 forwarding přes xpra je opravdu poněkud přes ruku. To snad už radši nějaký opravdový sandbox. Na Windows je možností víc, ale podle všeho by mělo stačit přebalit Win32 app pomocí Desktop App Converteru.
> Nevím proč to u vás jde. Nemáte náhodou vypnuté UAC?
Nie, ale som na W7. Mozno to MS odladil az neskor, alebo je skutocna chyba u Vas.
> A používat lokálně X11 forwarding přes xpra je opravdu poněkud přes ruku. To snad už radši nějaký opravdový sandbox.
Nie, to by dana aplikacia mala rovnake prava ako lokalna. Princip X11 sandboxu je cca taky, ze sa pusti X Server zvlast pre kazdu aplikaciu (skupinu) a nejaky kod len prehadzuje obrazky a eventy. Netvrdim, ze to znie pricetne, ale je to lepsie riesenie nez dufat, ze si vyvojar plesne po ruke sam a hodi to na Wayland alebo Windows.
Ten obrázek, to mne zaujalo. Jaká tam máte privilegia u user účtu, který posílá. Nezvýšená?
Když jsem si s tím kdysi hrál a testoval, tak pod WXP (a částečně i W2K) se mi to nepovedlo. Jedině pokud byl uživatel v "Power Users" nebo "Administrator" group. Ale možná jsem dělal něco blbě, žádná práva jsem si v runtime nepovyšoval a používal "jen" čisté PostThreadMessage.
Nicméně připouštím, že jsem tehdy user účty právy ještě ponižoval, možná jsem tam něco přidal (resp. omezil navíc).
Možná si odpovím sám. Pokud se pamatuji, netestoval jsem případ spuštěného admin úlohy pod user desktopem, ale s přepínáním uživatelů, remote desktop (+hack pro běh více uživatelů na XP najednou) a podobně. Je možné, že pod stejným desktopem (společné parent) by mi to na XP a nižších prošlo.
Hmm a není statická kompilace defakto to samé.
jaký je rozdíl mezi tím, že snappy mi nainstaluje požadované verze knihoven vedle mé aplikace a nebo tím, že to prostě zkopiluju staticky. No a v kontejneru si to pustím klidně sám.
Navíc mi příchod snapy a flatpaku přijde tak trochu s křížkem po funuse když už tak raději použijju docker.
....Hmm a není statická kompilace defakto to samé ...
no, ja nevim, jak je to dnes, drive (pred mnoha lety) to bylo tak, ze program, ktery mel posazeny sticky-bit (bit, ktery se dnes pouziva na neco jineho) sdilel svuj texttovy segment v pameti se vsemi instancemi toho sameho programu. Kdyz se tedy takovy program spustil 100 krat, tak byl v pameti 'vlastne' jen jednou. Tato strategie byla opustena, protoze se rozmohlo dynamicke linkovani a proto si myslim, ze pri pouziti statickeho linkovani by mohlo dochazet k problemu s nedostatkem pameti a take naklady na spusteni programu jsou mnohonasobne vetsi.
To vse neplati samozrejme v situaci, kdy spustim nejakeho demona, ktery bezi jen jeden a startuje se v bootu.
Asi to taky budu mít rád jako "j" systemd.
- Riziko, že jedna z 20 kopií knihovny v systému zůstane neaktualizovaná
- Riziko, že klient bude používat jinou verzi stejné knihovny, než server a zbytečný problémy z toho plynoucí
- U embedded systémů prostě nemám místo na několik kopií a výkon na virtualizaci. Chtěl bych vidět, co by s tím dělala Pidora na RPi2. Nebo v OpenWrt na něčem standardním...
- Vývoj a testování, no fajn, nebude se testovat proti pěti verzím knihovny, ale proti jedné s tím, že když budu dělat server, klient může mít pět verzí, konfigurátor taky pět verzí,... a nemám to konzistentní v rámci systému na jednom stroji. Brr. Exponenciálně to poroste s počtem spolupracujících "packů", používajících knihovnu.
Není nad apt a rpm.
- narust objemu prenasenych dat pro instalace/aktualizace
- narust velikosti zabraneho mista na disku
- narust spotrebovane pameti
- narust administrativni rezie kvuli nutnosti zaplatovat jednotlive instalace, misto jedne centralni aktualizace
- "resi" se dalsi virtualni problem, ktery v praxi neexistuje
Líbilo by se mi, kdyby si aplikace vyžádala různé knihovny a runtime Flatpaku by je automaticky stáhnul přes nativní balíčky distribuce na které běží, takže by se vyřešil problém s updaty i místem. A kdyby knihovna nebyla na distribuci dostupná, stáhla by se verze od poskytovatele aplikace.
Sak aplikace to rika, slovy vyvojare ... kterej casto sam netusi, co vsechno a v jaky konfiguraci je potreba, protoze nevi, jak to ma nastaveny sam.
Takze jedinej vysledek tyhle zhuverilosti bude, ze nejakej script pobere 80% jeho systemu, a ten ti narve do tvyho, aby to "zarucene" fungovalo.
Podivej se, jak vypada vetsina make souboru ... testujou tisice polozek 10 minut, aby se pak na 2 radcich za 2s prekompiloval hello world.