Chrome sandboxován v dockeru (diskuse)

[Max]

Moc pěkné, díky.
Zdar Max

[dumblob]

Hezke, diky. Mj. mam nyni brouka v hlave proc ALSA nejela. Nu a toho YubiKey je tez skoda.

[limit_false]

Toho Yubkey je škoda. Zkoušel jsem různé triky se zpřístupněním částí /sys a /dev/usb subsystémů, ale ani po dalším strace-ovaní se mi nepovedalo dohledat, v čem je konkrétně problém. Diffoval jsem stracy z host systému vs stracy z dockeru. Žádný podstatný rozdíl ale zatím neumím najít.

[ET]

docker neznam, budu se na nej muset podivat, ale celkem me zarazilo

echo "developer ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/developer

[limit_false]

To je tam spíš kvůli tomu, aby se rychle dali doinstalovat balíčky a pro ladění. Samozřejme sudo bez hesla funguje jen v kontejneru.

[ET]

pak bych to dopsal do zapisku a po instalaci/ladeni bych ten ucet odebral (jak rika kolega, jednotkou docasnosti je 1 furt)

jinak pekny zapisek, diky, budu se na ten docker muset podivat

[Jardík]

Má to ale jeden háček. Tím, že si dovolil chrome přístup na Xka se naprosto zbytečně snažíš o jeho izolaci. Pokud se bojíš nějaké špehovací šmejďárny v Chrome (přestože Google tvrdí, že je to Chromium + extra krávoviny, nikdy mu nemůžeš věřit, že to nemá extra špehovátka), a proto Chrome izoluješ, tak si selhal. Špehovací šmejďárna teď klidně může posílat ostatním aplikacím X eventy a ovládat je a kopírovat data, odposlouchávat hesla apod, jednoduše skrze Xka. Dalo by se to např. pořešit použitím waylandu uvnitř dockeru, jenže Chrome, narozdíl od Chromia, asi pod waylandem neběží.

[limit_false]

S tím problémem X-ek je mi to jasné. Ono by stejně nebylo dobré dávat mu přístup k host USB zařízením, pokud bych byl cíl obejít "šmejďárnu" v Chrome. To už pak nějaká úplná virtualizace.

Jako sandboxing je tenhle přístup spíš vhodný pro případnou obranu proti Chrome exploitu - exploit by musel velmi specificky jít po X funkcech. Když už bych měl takový problém, tak mám mnohem větší problém

Původně jsem tohle celé dělal kvůli rozběhnutí Chrome/Chromia na CentOS 6, kde Chrome nefunguje (příliš stará libc) a Chromium nelze přeložit. Není to můj hlavní prohlížeč, ale někdy se hodí. BTW překlad Chromia vyžaduje překlad celého speciálně upraveného gcc toolchainu kvůli nacl a pepperapi. To upravené gcc generuje kód, který se např. vyhýbá ret instrukci a dělá ruzné zarovnání, aby byl return-to-libc těžký.

S tím waylandem a Chromiem to ale není až tak špatný nápad, někdy to vyzkouším. Jak se vlastně wayland napojí na host X server? Neudělalo by to stejný problém? Jinak pořád lze provozovat místo komunikace přes X socket něco jako VNC, ale to už mi použitelnější přijde seamless mód Virtualboxu.

[smazáno]

Tech hacku je o dost vic. Takto prijde o automaticky updaty knihoven na kterych chrome zavisi (narozdil od pouziti systemove instalace), vsechen sitovy traffic jde z chrome pres extra NAT, ....

[smazáno]

Zajimavy. Jak resis respektovani systemoveho nastaveni ... od "blbyho" resolv.conf po uzivatelsky nastaveni fontu, antialiasing, tematu, ikonek atd. atd.

[limit_false]

Soubory se dají sdílet přes -v flag. Docker má speciální nastavení pro DNS, nepoužívá se resolv.conf (nebo se asi z toho nastavení generuje).

Témata jsem zatím nějak neřešil. Chrome vypadá jako kdyby ani v sandboxu neběžel, má ten svůj nativní vzhled. Jediný viditelný rozdíl je např. ve file chooser dialogu. Zřejmě by to šlo nastavit uvnitř kontejneru na stejné téma, jako požívá host systém.

[smazáno]

Zajimalo me to hlavne kvuli tomu, jak jsou dnes snahy prosazovat docker jako sandbox pro desktopve aplikace (GNOME, Ubuntu), tak jestli uz hosi nejak vyresili integraci - a koukam ze ne (predopkladam ze rozbiti konzistence celeho desktopu je pro ne "minor bug" jestli vubec), ze se stale musi resit vse pripad od pripadu.

btw. s/nativni/nenativni/;)

[Jardík]

Vzhledem k tomu, že vývojáři gnome/gtk každou chvíli rozbíjejí témátka a jeho změna je součástí jen gnome-tweak-tool, stejně tak písmo, tak bych se vůbec nedivil, že je to nezajímá. Prostě ti vhodí to svoje rozmazané a nečitelné písmo, jeho velikost a jejich téma a jesli budeš chtít něco jiného, tak "dodělej si sám".

[smazáno]

Ano.

[limit_false]

Po dalším hackování mi funguje U2F, ale zatím jenom pod rootem. Nevím zatím proč, protože USB zařízení sdílím přes /dev/bus/usb, /sys/devices, atd. a práva mají pro stejný UID/GID. Nicméně pod tím samým userem, kde funguje X a pulseaudio dostávám pro USB přístup chybu -EACCESS.

Dobrý testovací nástroj pro U2F je u2f-host.

[limit_false]

Vypadá to asi na nějaký bug v dockeru - zařízení /dev/ttyUSB* lze minicomem v dockeru připojit, ale USB hidraw Yubikey ne.

K USB je do spouštěcího skriptu potřeba doplnit:

    -v /dev/bus/usb:/dev/bus/usb \
    -v /sys/bus/usb/:/sys/bus/usb/ \
    -v /sys/devices:/sys/devices/ \
    --privileged \

[limit_false]

Záhada USB hidraw vyřešena, viz update v článku.