Vydání GNOME 3.20 se blíží, má vyjít 23. března, chcete-li si vyzkoušet, jaké novinky se objeví v aplikacích v tomto vydání, nemusíte si instalovat Rawhide nebo nějaký experimentální repozitář, který vám systém dokonale rozbije. "Noční" vydání vybraných aplikací GNOME můžete nyní jednoduše a izolovaně instalovat pomocí XdgApp.
Co je XdgApp? Jedná se o technologii, pomocí které lze provozovat desktopové aplikace v kontejneru. Více se o ní můžete dozvědět v článku, který na mojefedora.cz vyšel loni v květnu. Ve Fedoře 24 už by měla být podpora XdgApp v GNOME Software, takže spravovat tyto aplikace bude možné v grafickém rozhraní. Ve Fedoře 23 je stále potřeba používat konzolový nástroj xdg-app, ale instalace je relativně bezbolestná, jak ukazuje Alex Larsson, autor XdgApp, v návodu na svém blogu.
Úplně na začátek je potřeba mít poslední verzi xdg-app - 4.11. Ta se momentálně nachází ve Fedoře 23 v repozitáři updates-testing a nainstalujete ji příkazem:
# dnf install --enablerepo=updates-testing xdg-appNyní přidáte vzdálený repozitář:
$ curl -O http://sdk.gnome.org/nightly/keys/nightly.gpg
$ xdg-app --user remote-add --gpg-key=nightly.gpg gnome-nightly http://sdk.gnome.org/nightly/repo/Poté nainstalujete runtime, který aplikace ke svému běhu potřebují:
$ xdg-app --user install gnome-nightly org.gnome.PlatformSeznam aplikací, které daný repozitář obsahuje, získáte příkazem:
$ xdg-app --user remote-ls gnome-nightly --appVybranou aplikaci (v tomto případě Weather) pak nainstalujete a spustíte těmito příkazy:
$ xdg-app --user install gnome-nightly org.gnome.Weather
$ xdg-app run org.gnome.WeatherA výsledek:
Aktuální vývojová verze aplikace počasí ve Fedoře 23.
Momentálně aplikace XdgApp fungují jako bundly, dokáží tedy běžet nezávisle na verzích knihoven v systému. To umožňuje jednoduše instalovat aplikace, aniž byste museli aktualizovat systém. V budoucnu se plánuje, že budou také izolované a budou mít jasně definovaný přístup ke zdrojům a datům mimo kontejner. To by mělo zvýšit bezpečnost. Průkopníkem XdgApp je projekt GNOME, ale zájem o něj má také KDE a pro LibreOffice 5.2, které vyjde v srpnu, připravujeme také oficiální instalační soubor pro XdgApp. Uživatelé Fedory 24 tak nebudou muset čekat na nové vydání Fedory, aby mohli začít novou verzi LibreOffice, ale budou moct jednoduše nainstalovat otestovanou verzi z upstreamu.
15. 2. 2016 at 15:22
Dobrý den,
příliš se v problematice kontejnerů neorientuji, takže mám možná hloupý dotaz – nejdůležitější aplikaci která by dle mého měla běžet v kontejneru je firefox, ale nikde jsem nenašel návod pro bfu. Zvlášť když ve Fedoře nefunguje (už několik verzí) selinux sandbox pro grafické aplikace. Nebylo by možné nějaký takový návod nebo rovnou hotový kontejner s firefoxem poskytnout vašim uživatelům? Zrovna tak by mne zajímalo, jak do nějakého takového kontejneru umístit nějakou síťovou hru (třeba UrbanTerror). Nebo kontejnery slouží k něčemu jinému?
15. 2. 2016 at 17:24
S Firefoxem pro XdgApp se rozhodně počítá, ale momentálně má Firefox tým dost práce s přechodem na GTK 3 a podporou Waylandu. Takový Wayland také výrazně zvýší bezpečnost, protože dělá na úrovni display serveru to, co SELinux na úrovni souborového systému.
Do kontejneru lze umístit prakticky jakákoliv aplikace, jejich distribuce v kontejnerech má dvě zásadní výhody: 1. stačí udělat jednu instalačku a pojede na všech distribucích, které mají xdg-app. 2. umožňují aplikaci sandboxovat, takže jí není nutno tak důvěřovat.
Nutno říct, že sandbox není momentálně v XdgApp vynucovaný, takže zatím to má jen tu výhodu 1). Pracuje se na API, přes které bude aplikace kontrolovaně komunikovat se zbytkem systému, jinak bude izolovaná, pak bude platit i výhoda 2).
Je fér zmínit, že celé řešení má i své nevýhody: je tam vyšší paměťová náročnost a člověk se musí spoléhat, že autor aplikace nebo runtimu poctivě aktualizuje všechny obsažené komponenty.
16. 2. 2016 at 08:50
Děkuji za odpověď. Docela mne mrzí, že Fedora vsadila na Wayland, protože to znamená, že nebude (z principu) fungovat spousta věcí, které používám – od gest myší, přes xev, po samotný desktop manager (GNOME je pro mne naprosto nepřijatelné). A teď se dozvídám, že Wayland zpomaluje vývoj i jiných, potřebnějších věci. Jako by nestačil systemd…
16. 2. 2016 at 09:11
Fedora neměla moc na výběr, mohla se rozhodnout mezi Waylandem a Mirem, přičemž Wayland má mnohem širší podporu, takže to byla přirozená volba. Držet se X je dlouhodobě neudržitelné. Nakonec jsou to sami vývojáři X, kteří přišli s Waylandem, protože některé věci už v X nejde rozumně dělat. Nevím, proč by neměly jít gesta myší, to je především záležitost zpracování vstupních zařízení a už nyní se ve Fedoře používá jak pro X, tak pro Wayland stejná věc – libinput. Naopak s Waylandem jdou udělat věci, které nejsou rozumně možné s X – izolace aplikací, pořádná podpora hidpi,…
Pokud váš desktop manažer nepodporuje Wayland, tak není problém i nadále používat X, ve Fedoře budou minimálně dalších 5 let. Akorát s jeho vývojem to bude horší, protože se budou postupně vývojářské síly přesunovat na Wayland, ale to už se nějakou dobu děje.
16. 2. 2016 at 10:26
Pane Eischmann, fandím Waylandu a rád bych se na něj přepnul. Něco je jinak a něco se musí opravit, to je jasné. Ale je jedna věc, která mi vadí zásadně – po přihlášení se mi nenačte „~/.profile“, takže při otevření terminálu nemám svoje prostředí. (PATH, atd.)
Nevíte, jestli to tak zůstane (bude to vlastnost) nebo je to chyba, která se časem opraví?
16. 2. 2016 at 11:25
Je to známý problém, shoda na tom, že se to má vyřešit, je, jen se zatím nedohodlo jak. Nicméně ~/.bashrc by se po spuštění Terminálu mělo načítat, takže by tím neměl být tak zasažený.
16. 2. 2016 at 11:41
Dík za info.
16. 2. 2016 at 11:43
Nejsem expert na bezpecnost. Pro firefox sandbox pouzivam od asi F21 nasledovny script, nyni ve F23. Mapuje $HOME a /tmp do (puvodniho) $HOME/sbffox/home a $HOME/sbffox/tmp.
Stazene soubory budou tedy v $HOME/sbffox/home/Downloads, zkopirujte je nez zavrete firefox nebo zakomentujte rm … na konci skriptu.
#!/bin/bash
sbdir=$HOME/sbffox
# Check that firefox is not running, exit if yes.
ps -ef | grep „^$USER.*firefox$“
if [[ $? == 0 ]]; then
exit 1
fi
mkdir -p $sbdir/home $sbdir/tmp
chcon -t sandbox_file_t $sbdir/*
cp $(which firefox) $sbdir/home
cd $sbdir/home
seunshare -v \
–homedir=$sbdir/home \
–tmpdir=$sbdir/tmp \
— firefox
rm -R $sbdir
16. 2. 2016 at 14:03
dnf mi seunshare nenašel. Co to je a kde to roste? Dík
16. 2. 2016 at 14:45
Je to sucast balika policycoreutils … 🙂
16. 2. 2016 at 14:48
pripajam detailnejsie info …
https://apps.fedoraproject.org/packages/policycoreutils-sandbox/
17. 2. 2016 at 14:24
Ve skriptu jsou chyby, špatné uvozovky, místo „–homedir=$sbdir/home“ má být „–h $sbdir/home“ a podobně. Jak vám tohle v téhle podobě vůbec mohlo fungovat?
Ono to ale nefunguje ani když to napíšu správně, po namountování těch adresářů to ohlásí:
No protocol specified
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0
A Google mlčí…
Narozdíl od „sandboxu“ mlčí i audit.
Takže jsem zase na začátku – má, prosím, někdo FUNKČNÍ řešení sandboxování firefoxu ve Fedoře?
17. 2. 2016 at 14:45
No, bash z toho pustit lze. Takže tenhle slavný sandbox pana XX není žádný sandbox ale spíše nějaký nedomrlý chroot. Dostanu se všude (kromě home, který je přemountován), mohu spustit cokoliv, sestřelit jakýkoliv proces, mohu nahrát rootkit a spustit ho. Takže děkuji za pocit falešné bezpečnosti a lidem z Fedory za to, že řeší důležité věci.
17. 2. 2016 at 15:06
Ochrana desktopové aplikace přes SELinux je vždycky falešná bezpečnost. Je supr, že to člověk izoluje dokonale na úrovni file systemu, ale je mu to z velké části na prd, když má aplikace přístup ke všemu, co teče přes X server. Člověk jen zacpe jednu díru v děravém kbelíku.
XdgApp toto bude řešit komplexně, ale jasně deklarujeme, že v první fázi nebudeme vynucovat sandbox a tedy aplikace nebudou o nic zabezpečenější, jedinou výhodu to má v tom chytřejším bundlování. Na komplexní sandbox potřebujeme mít doladěný desktop na Waylandu a robustní IPC v kernelu a to ještě nějaký čas potrvá.
17. 2. 2016 at 15:46
Ano, souhlas, desktop s xorg je kapitola sama o sobě, ale co jsem se osobně setkal s malware na linuxu, tak ten nikdy nevyužíval X-ka, nýbrž díry ve flashi nebo Javě, většinou skrz Firefox. Byl jsem přesvědčený, že minimálně těm profláknutým vektorům by selinux zabránit měl. Bohužel ve Fedoře jsou selinuxová pravidla nastavena tak, aby uživatel nebyl nijak omezován – a tedy není nijak omezeno ani malware. Lze to pochopit, na druhou stranu vidím priority spíše v bezpečnosti a ochraně soukromí, než v rozvrtávání fungujícího initu.
XdgApp vypadá jako prospěšná věc, určitě ulehčí práci tvůrcům her a různého software z netradičních zdrojů. Je dobře, že jasně říkáte, že zabezpečení v první fázi nebude. Jako profesionální pesimista už přímo slyším, jak tvůrci malware hlasitě jásají. Zabundlují rootkit pomocí XdgApp a už je nemusí trápit rozdíly mezi distribucemi. Jak účinné.
Než bude rozumně fungovat Wayland a „robustní IPC“ tak už bude na každém motherboardu nějaké IPMI nebo AMT v takové kvalitě, že nějaká bezpečnost na úrovnii software bude stejně zbytečná.
18. 2. 2016 at 08:54
Sorry. Nevsim jsem si, priliz chytry formatovac. Zmenilo to ‚\-\-‚ (dva ‚-‚) na rozdelovnik… Pokus c. 2
seunshare -v \
\-\-homedir=$sbdir/home \
\-\-tmpdir=$sbdir/tmp \
\-\- firefox
18. 2. 2016 at 08:58
Tak ani poklus 2. nevysel 🙁 Snad alespon je videt, co bylo umyslem…
16. 2. 2016 at 16:47
# Odkud je seunshare instalovan?
dnf provides *bin*seunshare
# Install
dnf install policycoreutils-sandbox.x86_64
16. 2. 2016 at 17:09
díky, v tom policycoreutils-sandbox to skutečně je. Vyzkouším. Jsem poněkud zmaten z toho, že těch „selinuxových sandboxů“ je vícero a návody na googlu jsou nefunkční. Co jsem se natrápil s desítkami různých mutací „sandbox -X -t sandbox_web_t /usr/bin/firefox“. Ve Fedoře nefunguje žádná z nich – selinux zařízne Xephyr a je vymalováno. Uvidím, zda seunshare bude úspěšnější.
27. 4. 2016 at 04:03
> člověk se musí spoléhat, že autor aplikace nebo runtimu poctivě aktualizuje všechny obsažené komponenty
toto vidim ako hlavny bezpecnostny problem celeho XdgApp konceptu
27. 4. 2016 at 10:20
To jistě riziko je, nicméně bundly budou spravované přímo distribucí nebo velkým upstreamovým projektem (GNOME, KDE,…) a tam nemám o nic menší důvěru, že budou udržované, než, že si správce balíček poctivě záplatuje v distribuci.
U přibundlovaných věcí to závisí na autorovi aplikace, ale ti bundlují už nyní. U XdgApp ten bundle aspoň poběží v relativně slušně izolovaném sandboxu.