Vlákno názorů k článku Postřehy z bezpečnosti: zlé, zlé USB od klusacek - Co brani ve zmene Linuxoveho jadra v tom...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 10. 2014 11:55

    klusacek (neregistrovaný)

    Co brani ve zmene Linuxoveho jadra v tom smyslu, ze pocitac muze mit jen jednu klavesnici? Kdyz bych chtel pridat dalsi, musel bych to jadru explicitne rict.

    Kde delam chybu kdyz si myslim ze by se to tim vyresilo? Nechme stranou pripady ze utocnik prijde, odpoji USB klavesnici a pripoji svou flashku, predstavme si notebook kde odpojovani klavesnice neni tak snadne...

  • 6. 10. 2014 12:00

    Karel (neregistrovaný)

    Ochrana by fungovala. Akorát byste musel řešit BFU, kteří by si stěžovali, že kvůli výměne klávesnice musí kupovat nový počítač.

  • 6. 10. 2014 12:09

    j (neregistrovaný)

    Mozek si zapomel nekde na ulici? To si vazne myslis, ze klavesnice je jediny zarizeni ktery lze podvrhnout? Kdyz na to prijde, muzu ti trebas vsechny exe soubory na ty flashce doslova za chodu patchovat, takze kdyz si ze zcela standardniho masstorage neco spustis, tak se spusti i muj kod, kterej mam nekde, pro tebe neviditelne, schovanej.

    ALe viz vejs, presne totez lze delat se zcela libovolnym kusem HW.

  • 6. 10. 2014 16:01

    klusacek (neregistrovaný)

    Ze standardniho mass-storage zasadne nic nespoustim. To bylo nebezpecne uz pred tim.

    Dobra, je tu jeste problem nekterych pocitacu (jako treba R-pi), ktere maji bezne periferie, jako treba sit pripojene pres USB, nebo nekteri hazarderi pouzivaji USB prevodniky pro wifi apod. Tam uznavam by to nebylo 100%, i kdybych to omezil na 1 dovolene zarizeni, protoze to utocnik muze odpojit a pripojit misto toho co chce on a tim ze USB nema podepsana zarizeni tak pocitac nepozna ze to co tam utocnik pripojil uz neni ta puvodni wifina.

  • 7. 10. 2014 10:40

    ebik (neregistrovaný)

    Ale i to mass-storage muze mit oeditovany firmware takze krome mass-storage se vam tam pripoji navic klavesnice, sit a dalsi veci.

  • 6. 10. 2014 14:38

    aaa (neregistrovaný)

    Takze zakazeme externu klavesnicu k notebooku?

    Nie je problem zakazat pripajanie USB a selektivne ich povolovat.

  • 6. 10. 2014 16:05

    klusacek (neregistrovaný)

    Predstavoval jsem si to tak, ze v okamziku kdy budu chit pripojit externi klavesnici udelam neco jako echo 2 >/proc/.../enabled-keyboards a pripojim externi klavesnici.
    Kdyz ji pak nekdo odpoji, spadne to cislo automaticky na jednicku.

    `Nie je problem zakazat pripajanie USB a selektivne ich povolovat.'

    Myslite tou vetou ze uz je to v jadre? Jak se to dela?

  • 10. 10. 2014 16:11

    M. Prýmek

    Přečetl jsem tu diskusi a myslím, že (stejně jako ta prezentace na BlackHatu) jde na ochranu ze špatné strany - snaha softwarově řešit, jaké zařízení je připojeno místo zabezpečení toho, aby zařízení nemohlo uškodit.

    Místo toho by to imho spíš chtělo uvažovat nad:

    1. jak se u svých zařízení ujistit, že nejsou flashnutelná (snad by to údajně mohla řešit FIPS level 3 certifikace - detaily jsem nezkoumal - viz http://www.tresys.com/products/badusb.php ) ale ujištění důvěryhodného výrobce by snad mělo pro normálního smrtelníka stačit...

    2. zamezit možnosti eskalace práv jenom pomocí fake klávesnice - sudo je prostě extrémně nebezpečná věc, tak jako tak raději používat klasicky "su -" a v případě potřeby dvoufaktorovou autentizaci nebo třeba OTP. Tím by se zamezilo nebo aspoň výrazně ztížilo šíření.

    3. pokud mám strach i o svoje vlastní data (rm -rf $HOME), tak zamknout Xka, přepnout se pod spešl uživatele, soubory překopírovat do /tmp a odtud k sobě. Ideálně mít takovou sešn, která má jenom terminál a nic jinýho - všechny divné keystroky snadno uvidím...

  • 10. 10. 2014 22:36

    Jenda (neregistrovaný)

    > snaha softwarově řešit, jaké zařízení je připojeno místo zabezpečení toho, aby zařízení nemohlo uškodit

    Nj, ale jak jinak než softwarem bys chtěl filtrovat, co za typ USB zařízení se zdetekuje, případně kam mi která klávesnice může psát?

    > 1. jak se u svých zařízení ujistit, že nejsou flashnutelná

    Ale já chci mít svá USB zařízení flashnutelná. Chci mít možnost nahrávat do nich alternativní FW a používat je k různým jiným účelům.

    Navíc to neřeší kamaráda „nahraj mi to na flashku“.

    > zamezit možnosti eskalace práv jenom pomocí fake klávesnice - sudo je prostě extrémně nebezpečná věc

    sudo samozřejmě může vyžadovat (a defaultně vyžaduje) heslo. Mně je ale úplně jedno, jestli mi na počítači získají roota - tu největší škodu (ukradení a následné smazání důležitých informací) napáchají pod uživatelem, root není vůbec potřeba.

    > 3. pokud mám strach i o svoje vlastní data (rm -rf $HOME), tak zamknout Xka, přepnout se pod spešl uživatele, soubory překopírovat do /tmp a odtud k sobě. Ideálně mít takovou sešn, která má jenom terminál a nic jinýho - všechny divné keystroky snadno uvidím...

    Není fakt asi milionkrát jednodušší prostě nedovolit cizímu člověku/zařízení psát mi do session?

  • 11. 10. 2014 1:04

    M. Prýmek

    > Ale já chci mít svá USB zařízení flashnutelná.

    Potom musíš být připraven nést riziko a jsi natolik netypický uživatel, že tvůj use case prakticky nemá smysl řešit.

    > sudo samozřejmě může vyžadovat (a defaultně vyžaduje) heslo.

    Ano, ale default pro timestamp_timeout je 5 minut a skript toho může celkem snadno využít.

    > Mně je ale úplně jedno, jestli mi na počítači získají roota -

    Pokud získá roota, tak navíc i kompromituje celý stroj, to je ten rozdíl. Že je to tobě jedno, to jsme všichni moc rádi, že to víme, ale existuje spousta lidí, kterým to jedno není. Např. všichni správci strojů s víc než jedním uživatelem.

    > tu největší škodu (ukradení a následné smazání důležitých informací) napáchají pod uživatelem

    Proto je tam ten bod 3. Pokud flashka může vkládat znaky do terminálu uživatele dumb, tak těžko může ukrást data uživatele jenda. ...a jsme u důležitosti nezískání roota.

    > Není fakt asi milionkrát jednodušší prostě nedovolit cizímu člověku/zařízení psát mi do session?

    Ne, protože není vůbec jednoduché vymyslet neprůstřelný mechanismus, pomocí kterého bys odlišil legitimní a nelegitimní klávesnici.

    Asi nejlepší možnost je zobrazit na monitoru nějakou náhodnou sekvenci, kterou bys musel na nové klávesnici vyťukat, aby začala fungovat. Jenže narazíš na problém, kdo by měl takové okno zobrazit atd. Mně osobně teda přijde milionkrát jednodušší podezřelá zařízení prostě ke své session vůbec nepustit.

  • 11. 10. 2014 14:31

    Jenda (neregistrovaný)

    > Potom musíš být připraven nést riziko a jsi natolik netypický uživatel, že tvůj use case prakticky nemá smysl řešit.

    LOL, připojovat si k USB programovatelná zařízení je extrémní usecase :-D :-D Teda ono je to spíš k pláči.

    Máš mobil s OTG?

    > Pokud získá roota, tak navíc i kompromituje celý stroj, to je ten rozdíl.

    Pro mě to rozdíl není. Popisoval jsem usecase na osobním desktopu. (tvůj usecase s víceuživatelským počítačem je pro mě stejně vzdálený jako pro tebe představa, že by někdo chtěl používat programovatelná USB zařízení) Pak ještě spravuju servery, ale tam většinou nepřipojuju USB zařízení, a nejsem nalogovaný v konzoli, takže falešná klávesnice si může psát tak akorát do login promptu.

    > Pokud flashka může vkládat znaky do terminálu uživatele dumb, tak těžko může ukrást data uživatele jenda. ...a jsme u důležitosti nezískání roota.

    Ano, to přepnutí se na jiného uživatele a práci s USB s ním je dobrý hack, i když dost přes ruku. Uživatel dumb samozřejmě nemá v sudoers povolené sudo.

    > Asi nejlepší možnost je zobrazit na monitoru nějakou náhodnou sekvenci, kterou bys musel na nové klávesnici vyťukat, aby začala fungovat.

    Já bych si zvolil buď sekvenci (je to první klávesnice/myš v systému, není, jak odkliknout potvrzení), nebo prostě dialogové okno. Jako když máš VmWare a připojíš si USB zařízení a on se tě zeptá, jestli ho chceš připojit do hosta nebo guesta.

    > Jenže narazíš na problém, kdo by měl takové okno zobrazit atd.

    To není problém toho řešení, to je problém mizerných operačních systémů, které v roce 2014 neumí na desktopu zobrazit notifikaci.

    > Mně osobně teda přijde milionkrát jednodušší podezřelá zařízení prostě ke své session vůbec nepustit.

    Pokud to tvůj usecase umožňuje, tak klidně. Co když bych ale chtěl ze své session na net (musím přes USB připojit mobil, který se chová jako modem), chtěl realtime zpracovávat signály se softwarově definovaného rádia (USB, jak jinak) atd.?

  • 12. 10. 2014 10:42

    M. Prýmek

    > LOL, připojovat si k USB programovatelná zařízení je extrémní usecase :-D

    Připojovat zařízení, která *někomu půjčuješ* a zároveň požadovat, aby u nich šlo přeprogramovat usb stack je *neobvykly* use case.

    > Pro mě to rozdíl není.

    Ještě jednou: potřebuje roota, aby se mohl šířit. Virus, který se nemůže šířit, není virus.

    > takže falešná klávesnice si může psát tak akorát do login promptu.

    Nebo do ssh session, otevřené v terminálu na tom tvým desktopu.

    > nebo prostě dialogové okno.

    Což vyžaduje kooperaci userlandu. Takže zase nějaká komunikace přes dbus. A když budeš v krizové situaci, klient ti nepoběží nebo dbus spadne, tak klávesnici nepřipojíš. Pokud nemáš druhý stroj přes který se sshčkneš, tak pom;že jenom restart. Hurá vzhůru k Windows.

    > to je problém mizerných operačních systémů, které v roce 2014 neumí na desktopu zobrazit notifikaci.

    Umí. Ale přidává to dalších x points of failure a klávesnice je natolik klíčová věc, že potřebuješ, aby fungovala i v největších krizovkách.

    > Co když bych ale chtěl ze své session na net (musím přes USB připojit mobil, který se chová jako modem), chtěl realtime zpracovávat signály se softwarově definovaného rádia (USB, jak jinak) atd.?

    Pokud to zařízení nikomu nepůjčuješ, je riziko jeho zavirování výrazně menší. Navíc ani jedno z těch zařízení nutně nemusí mít flashnutelný usb stack.

  • 12. 10. 2014 10:43

    M. Prýmek

    > Navíc ani jedno z těch zařízení nutně nemusí mít flashnutelný usb stack.

    Anebo se vrátit ke staré dobré metodě: chci flashovat, přepojím nějaký jumper. Bez toho to prostě nejde.

  • 12. 10. 2014 13:15

    Jenda (neregistrovaný)

    > Což vyžaduje kooperaci userlandu. Takže zase nějaká komunikace přes dbus. A když budeš v krizové situaci, klient ti nepoběží nebo dbus spadne, tak klávesnici nepřipojíš.
    > Umí. Ale přidává to dalších x points of failure a klávesnice je natolik klíčová věc, že potřebuješ, aby fungovala i v největších krizovkách.

    Na desktopu se mi tohle nestává (že bych připojil klávesnici až *potom*, co se něco rozbilo), na serveru to, jak už jsem psal, neřeším.

    > Nebo do ssh session, otevřené v terminálu na tom tvým desktopu.

    Asi jsem to špatně napsal. Mluvil jsem o připojování zařízení lokálně k tomu serveru.

    > Připojovat zařízení, která *někomu půjčuješ* a zároveň požadovat, aby u nich šlo přeprogramovat usb stack je *neobvykly* use case.
    > Pokud to zařízení nikomu nepůjčuješ, je riziko jeho zavirování výrazně menší. Navíc ani jedno z těch zařízení nutně nemusí mít flashnutelný usb stack.

    Co ten mobil s OTG, tedy snad každý smartphone?

    (1) Ten má softwarově libovolně upravitelný stack tak nějak z definice a bez toho by to asi nefungovalo.

    (2) Většina jich je snadno kompromitovatelná ze sítě mobilního operátora.

    (3) I když vyloučíme kompromitaci ze sítě operátora, je debilní, aby se prostě viry mohly jen tak šířit.

    Suma sumárum připojuju nedůvěryhodné zařízení, i když jsem ho nikomu nepůjčil, a nemám moc na výběr.

    > Anebo se vrátit ke staré dobré metodě: chci flashovat, přepojím nějaký jumper. Bez toho to prostě nejde.

    Takže půjčím kamarádovi/úřed­nici, aby mi něco nahrála/zákaz­níkovi/whatever, on ten jumper přehodí a vyhackuje mě. Super.

  • 12. 10. 2014 16:11

    M. Prýmek

    > Na desktopu se mi tohle nestává
    > Mluvil jsem o připojování zařízení lokálně k tomu serveru.

    Jenze kdyz se nejaka takova vec zavede, tak bude pravdepodobne fungovat stejne na desktopu i serveru.

    > Takže půjčím kamarádovi/úřed­nici, aby mi něco nahrála/zákaz­níkovi/whatever, on ten jumper přehodí a vyhackuje mě.

    Ne. Na to budes mit flashku, ktera preprogramovat nejde. Nevim, proc bys potreboval preprogramovatelnou flashku.

  • 13. 10. 2014 1:19

    Jenda (neregistrovaný)

    > Jenze kdyz se nejaka takova vec zavede, tak bude pravdepodobne fungovat stejne na desktopu i serveru.

    Distribuce, pokud nemá zvlášť profil balíčků pro desktop a server, by to mohla natáhnout třeba s Xkama, to je taková věc, co na desktopu je vždycky a na serveru skoro nikdy. Nebo by to prostě bylo defaultně vypnuté a uživatel by si to mohl zapnout, když by chtěl.

  • 11. 10. 2014 1:09

    M. Prýmek

    Jo a málem bych zapomněl, toho roota virus samozřejmě potřebuje k šíření, bez něj se na další flashku nezkopíruje, takže to je pro úspěšnost takového viru klíčová věc.

  • 13. 10. 2014 17:30

    Lael Ophir (neregistrovaný)

    1. Pokud virus nemá roota, může se šířit jinými způsoby - třeba kontaktovat okolní počítače po síti. Navíc snahou autora nemusí být virus nezbytně replikovat (i když to pak nespadá pod striktní definici počítačového viru). Velkým bezpečnostním problémem je i nákaza jednoho stroje v profilu uživatele. Lze ukrást data, smazat data, rozesílat spam, těžit bitcoiny, downloadovat další malware...

    2. Tohle je závažnější. Pokud si myslíte, že si na Linuxu můžete bezpečně jako restricted user otevřít terminál a přihlásit se jako root, tak se zásadně mýlíte. Máte totiž vychytávku zvanou X11 events. X11 events se posílají kdykoliv stisknete klávesu nebo uděláte cokoliv s myší. Jakákoliv aplikace je může jak poslouchat, tak generovat. Jinými slovy pokud si otevřete terminál a napíšete "su", může tohle a všechny další stisknut klávesy zachytit jakýkoliv program běžící ve vaší session. Stejně je to s jakýmkoliv jiným zadáváním hesla. A podobně může jakákoliv aplikace poslat události stisku kláves oknu terminálu (čtěte: namluvit mu že jste něco napsal na klávesnici), nebo jakékoliv jiné aplikaci. Další možností je dát text do clipboardu a poslat cílové aplikaci event, kterým sama obsah clipboardu vloží (řekněme prostřední tlačítko myši v terminálu).
    http://theinvisiblethings.blogspot.cz/2011/04/linux-security-circus-on-gui-isolation.html

  • 13. 10. 2014 17:40

    M. Prýmek

    > třeba kontaktovat okolní počítače po síti.

    Bavime se o nebezpecnosti te prezentovane moznosti preprogramovat flashku.

    > Velkým bezpečnostním problémem je i nákaza jednoho stroje v profilu uživatele.

    Virus se musi nejak sirit. Pokud se nesiri, tak neni potreba si s nim lamat hlavu. Vadi ti treba, ze nejaky clovek v Australii ma na pocitaci nejaky malware, ktery se dal nesiri?

    > Pokud si myslíte, že si na Linuxu můžete bezpečně jako restricted user otevřít terminál a přihlásit se jako root, tak se zásadně mýlíte.

    Ne, to si nemyslim, ale je to aspon odolne proti hloupemu utoku "spustim kdykoli a kdekoli sudo xxxxxxxxx". Zneuzit okna, ve kterem je spustene su je daleko tezsi, prihlasuje se tam jinym heslem atd. atd.

    Samozrejme to neni "bezpecne" ve smyslu "neprustrelne" - staci hloupost typu "do bashrc dam PATH takovy, ze se spusti uplne jine su". Jenze svete div se - zatim se neobjevil malware, ktery by toho masove zneuzil. Uz jenom proto, ze uzivatelu Linuxu je malo.

    Takovouhle argumentaci "ale to jde prece zneuzit" vymyslim proti vsemu - i kdyz mam smartcartu, tak pin nekam zadavam - nekdo mi ho muze ukrast a potom uz si podepisovat co chce jak chce (dokud je ta SC v pocitaci). No, jde to. A?

  • 13. 10. 2014 19:35

    Lael Ophir (neregistrovaný)

    Ad Vadi ti treba, ze nejaky clovek v Australii ma na pocitaci nejaky malware - vadí mi, že když půjčím někomu klíčenku, může ji vložit do stroje a vrátit ji nakaženou. Jistě si vzpomenete, že šíření virů přes výměnná média bylo svého času velmi populární. U USB klíčenek nás dost chrání to že firmware pro různé modely se nejspíš dost liší, a že flash klíčenky potřebuje oprávnění admina.

    Ad zneuzit okna, ve kterem je spustene su je daleko tezsi - není to nijak těžké, a zvládne to třeba doplněk pro browser. Absence oddělení procesů běžících v různých kontextech, ale v jedné session, je velký bezpečnostní problém. MS se to alespoň snaží nějak řešit (integrity level, secure desktop). Na Linuxu máte holt smůlu. Pravda je, že vás do značné míry chrání minimální rozšíření Linuxu.

  • 13. 10. 2014 20:10

    M. Prýmek

    > vadí mi, že když půjčím někomu klíčenku, může ji vložit do stroje a vrátit ji nakaženou.

    Proto je potreba se poohlidnout po takove klicence, ktera proste zvenku flashovatelna neni (pokud se tohoto nebezpeci bojim).

    > Jistě si vzpomenete, že šíření virů přes výměnná média bylo svého času velmi populární.

    Ano, do té doby, než Microsoft pochopil, k čemu jsou takové věci jako oddělení uživatelů, systému, přístupová práva.

    > není to nijak těžké, a zvládne to třeba doplněk pro browser.

    Není to těžké technicky, ale "organizačně" - útočící software by musel poznat správnou příležitost, protože kdyby psal jenom tak mírnixtýrnix kamkoli, byl by hodně rychle odhalen.

    > MS se to alespoň snaží nějak řešit (integrity level, secure desktop). Na Linuxu máte holt smůlu.

    Tipoval bych, že to bude řešit Wayland, ale tyhle věci nesleduju, z praktického hlediska to žádný velký problém není.

  • 13. 10. 2014 20:20

    M. Prýmek

    Nebo jestli jste myslel oddělení procesů jako takových (ne jenom na desktopu), tak tam jsou na tom unixové systémy daleko líp než MS - zóny, jaily, lxcontainers, OpenVZ... To jsou věci, které se už nějakých deset let používají, není to nějaká vize ve výzkumné laboratoři MS.

    Dá se to hnát až takhle daleko https://qubes-os.org/ když je chuť.

  • 13. 10. 2014 22:16

    Lael Ophir (neregistrovaný)

    Jail vám nepomůže, a virtualizovat aplikace (tak jako lxcontainers, OpenVZ, qubes) můžete samozřejmě na Windows, ovšem je to poněkud HW náročné.

    V případě Qubes OS sice máte aplikace (draze) virtualizované a mezi jednotlivými AppDomains netečou X11 events, ale pořád tečou mezi aplikacemi v každé doméně, a případný útok za použití klíčenky by se týkal Dom0. Takže si asi moc nepomůžete.

  • 13. 10. 2014 22:42

    M. Prýmek

    Jasně, na Windows můžu použít třeba Hyper-V, to je jedna z mála věcí od MS, která aspoń na první pohled vypadá fakt slušně. Dokonce i iSCSI už to umí a ovládá se to hezky, je to fajn.

    Ale kontejnery jsou dost něco jiného, to na Windows nemáte (AFAIK). Pořád zmiňujete "drahou" virtualizaci, to kontejnery fakt nejsou - když to zjednoduším na dřeň, tak jsou to pořád úplně stejné procesy, akorát mají jenom flagy, kam můžou a nemůžou. Dopad na výkon je minimální.

    > a případný útok za použití klíčenky by se týkal Dom0

    Tak to ani náhodou, protože pod Dom0 neběží nic, na co by jakýkoli usb zařízení mohlo jakkoli zaútočit (když předpokládáme, že nezneužívá nějakou chybu v ovladači v jádře, což je jiná kapitola).

  • 14. 10. 2014 0:31

    Lael Ophir (neregistrovaný)

    S Hyper-V mám celkem dobré zkušenosti, minimálně ve srovnání s VMwarem.

    Qubes OS podle všeho provádí virtualizaci pomocí Xenu. To je drahé. Pokud se mýlím, rád se samozřejmě dozvím víc.

    Windows mají job objects, ale podobně jako kontejnery to asi moc nepomůže.
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms684161(v=vs.85).aspx

    Problém je v tom, že aplikace na desktopu spolu běžně mají interakci. Potřebujete používat clipboard, drag and drop, procesy si posílají window messages atd. Když začnete window messages filtrovat, spoustu věcí rozbijete.
    MS to řeší tak, že procesy mají přiřazený integrity level od SECURITY_MANDA­TORY_UNTRUSTED_RID až po SECURITY_MANDA­TORY_SYSTEM_RID. Proces s nižším integrity levelem nemůže poslat window message procesu s vyšším integrity levelem. Procesy běžící v kontextu členů skupiny Administrators mají by default integrity level SECURITY_MANDA­TORY_HIGH_RID. Důsledkem je, že když si coby restricted user spustíte cmd.exe jako administrátor (i přes UAC), tak mu nepošlete window message. Není to dokonalé, ale alespoň to zajistí, že například browser běžící s nízkým levelem intergity v případě bezpečnostního problému nemůže posílat window messages ostatním aplikacím.
    http://msdn.microsoft.com/en-us/library/bb625963.aspx

    K tomu mají Windows Secure Desktop. To je třeba taková ta obrazovka na které potvrzujete UAC elevation. Tenhle desktop je z hlediska window messages izolovaný. Kdyby to tak nebylo, aplikace by mohla triviálně oknu s výzvou pro potvrzení akce poslat stisk klávesy pomocí window message (jako na Linuxu).

    Z podobných důvodů MS zakázal servisům (deamonům) přístup k desktopu.

  • 14. 10. 2014 1:00

    M. Prýmek

    > S Hyper-V mám celkem dobré zkušenosti, minimálně ve srovnání s VMwarem.

    Na jednu zásadní nevýhodu jsem narazil: zvolený typ virtuální síťovky. Dát tam hardware, pro který není ovladač ani ve starších Windows, to nebyl moc dobrý nápad. Bez support tools (nebo jak se to jmenuje) si člověk ani neškrtne.

    A přitom stačilo přidat nějaký standardní, všude podporovaný hw jako v tom VMWaru nebo VirtualBoxu. Nejspíš to MS udělal proto, aby měl kontrolu nad tím, co bude člověk vevnitř pouštět. Haiku si tam nejspíš člověk nepustí kdyby se na hlavu stavěl...

    > Qubes OS podle všeho provádí virtualizaci pomocí Xenu. To je drahé.

    Je to IMHO hlavně spíš proof-of-concept, nikdo to reálně nepoužívá.

    No, drahé... V dnešní době je ta virtualizace tak zamotaná, že už není moc jasný, co je drahé. Samotná režie je už u všech řešení tak malá, že to zásadní problém není. Rozhodují spíš takové věci jako že třeba u kontejnerů (zón, jailů) je jedno jádro, takže i jedna knihovna může být za nějakých podmínek v paměti jenom jednou. Plus výkon virtualizovaného hw, jeho hw akcelerace. Takže tady mají opět kontejnery obrovské plus. Jak je na tom Xen, to netuším, nepoužívám ho.

    Určitě by bylo lepší v tomhle případě použít kontejnery, ale ty ještě nejsou dostatečně odladěné z hlediska bezpečnosti, takže asi proto XEN.

    > Windows mají job objects

    No jak koukám na to API, tak to moc o bezpečnosti není, spíš o nějakém společném plánování a řízení.

    > Proces s nižším integrity levelem nemůže poslat window message procesu s vyšším integrity levelem.

    V Linuxu se teď spousta meziprocesové komunikace řeší přes DBUS, tam jsou omezení podstatně jemnější:

    http://www.redhat.com/magazine/003jan05/features/dbus/#security

    Nemluvě o MAC - AppArmor, SELinux.

    Už dávno neplatí, že je jenom root a uřivatelé. Dá se udělat prakticky cokoli, ale ne každý si s tím hraje, obzvlášť na desktopu to moc nemá reálný význam, protože prostě malwaru je tak málo, že to v podstatě není potřeba řešit, i když by to šlo.

    > K tomu mají Windows Secure Desktop. ... Z podobných důvodů MS zakázal servisům (deamonům) přístup k desktopu.

    No jo, ale až od Win Vista. A kolik programátorů si kvůli tomu rvalo vlasy, protože teď najednou museli mít zvlášt službu a zvlášť ještě aplikaci obsluhující ikonku v oznamovací oblasti :)

    Ono, u Windows je dost těžký se *v reálu* bavit o bezpečnosti, protože to vám přijde dodavatel sw a řekne "No jo, ale paní účetní musí pracovat s admin právy, jinak jí nebudou fungovat updaty". A není to jedna firma, tohle je naprosto běžný. U jedné velké firmy, která má prakticky monopol na jistou oblast účetnictví jsem o tom musel mluvit přímo s členem představenstva, který mi sdělil, že ano, mám naprostou pravdu, že by účetní neměla mít admin práva, ale že to po nich prakticky nikdo nechce - a to dodávají hodně do státní správy - takže tuhle možnost nemají úplně dobře odladěnou.

    Takže tak no. Když v reálu 9 z 10 účetních jede úplně všechno "pod rootem", tak je trochu úsměvný bavit se o messagingu mezi aplikacemi na jednom a tomtéž desktopu :)

  • 14. 10. 2014 3:16

    Lael Ophir (neregistrovaný)

    Ad Hyper-V a typ síťovky - používám Integration Services (jsou mimochodem i pro Linux), takže mě to netrápí. Haiku jsem nezkoušel, ale support pro DEC 21140 by měl mít.
    http://code.metager.de/source/history/haiku/src/add-ons/kernel/drivers/network/dec21xxx/dev/Jamfile

    Ad Qubes OS je spíš proof-of-concept - souhlas

    Ad job objects - samozřejmě umí nastavovat kvóty na CPU, paměť a I/O, ale vyjma toho umí také nastavit omezení, která by vlastník procesu jinak neměl. Dá se to kombinovat s integrity levels, přesunem aplikace na separátní desktop atd.
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms684152(v=vs.85).aspx

    Ad D-BUS - myšlenka je to dobrá (i když se skalním Unixákům nelíbí, prý je to moc Windows-like), ale problém to neřeší, protože máte pořád spoustu starých aplikací.

    Ad MAC - to je samozřejmě také možnost. Jenže takový systém je velmi obtížné používat, natož administrovat. Integrity levels ve Windows jsou mimochodem také MAC.

    Ad MS zakázal servisům (deamonům) přístup k desktopu až od Win Vista - ono to bylo popsané v dokumentaci jako bad practice delší dobu, a MS na to vývojáře upozorňoval léta před uvedením Visty.

    Ad v reálu 9 z 10 účetních jede úplně všechno "pod rootem" - s UAC jim to předpokládám moc nefunguje, protože uživatel je restricted i pokud se přiloguje jako admin. Ono dodavatele těžko předělat najednou. Ale když na dodavatele uživatelé křičí, že nechtějí UAC hlášky, a admini křičí že UAC rozhodně nevypnou :), tak to časem má efekt.

  • 14. 10. 2014 10:34

    M. Prýmek

    > i když se skalním Unixákům nelíbí, prý je to moc Windows-like

    Mně se nelíbí, pokud je použit k nastavování systémových věcí a bez něj to nejde. Na desktopu je to super věc, když můžete pod normálním uživatelem třeba přepínat wifi sítě, ale na serveru chci mít totální kontrolu nad tím, co se děje, nechci zbytečně nastavovat nějaká pravidla a chci, aby základní věci fungovaly za co největšího množství situací (tj. co nejmíň podmínek, KISS princip). Ale pro desktop aplikace je to parádní věc.

    BTW, existuje pro Windows COM+ něco jako qdbusviewer (můžu procházet všechny objekty na DBUSu, dívat se, jaká implementují rozhraní a spouštět metody)?

    > s UAC jim to předpokládám moc nefunguje, protože uživatel je restricted i pokud se přiloguje jako admin.

    Protože jsem to od začátku odmítal a raději instaloval updaty ručně, tak nevím. Předpokládám, že program prostě vyvolal UAC hlášku. A jelikož účetní potvrdí všechno, co vidí, tak jsme tam, kde jsme byli.

    > tak to časem má efekt.

    Ano, funguje to. Pomalu, ale jistě se dodavatelé učí psát aplikace pořádně. Jenom škoda, že to trvalo tak dlouho, mohli se to učit hned ze startu, jako na unixoidních systémech. Tohle Microsoftu prostě nemůžu odpustit, že ty prasárny lidi naučil, to se nedá oddiskutovat. Tyhle problémy prostě vůbec nemusely být, malware nemusel být takový problém... kdyby MS převzal léty prověřené unixové principy.

  • 13. 10. 2014 22:03

    Lael Ophir (neregistrovaný)

    Ad je potreba se poohlidnout po takove klicence, ktera proste zvenku flashovatelna neni - jak jí poznám?

    Ad šíření virů přes výměnná média; Microsoft pochopil, k čemu jsou takové věci jako oddělení uživatelů, systému, přístupová práva - jak jsem už psal, malware může provádět neplechu i pod restricted userem.

    Ad útočící software by musel poznat správnou příležitost - zjevně je to prakticky zneužitelné. Pokud jde o klíčenky, tak si uvědomte, že máte i zpětný kanál. Když například pošlete klávesy na spuštění PowerShellu a přepnutí NumLocku, dostanete na "klávesnici" od OS potvrzení, že se PowerShell opravdu podařilo spustit. Podobně můžete otestovat další platformy. Vlastní nasazení malwaru může proběhnout prostým založením skriptu, přes base64 dekodér, podvrhnutím souborů na USB Mass Storage, podvržením USB síťové karty atd.
    Jakmile malware dostanete na stroj (což může být věc jedné sekundy), není problém zahladit případné neúspěšné pokusy, zjistit jestli máte roota, nasadit rootkit, stáhnout další malware, uploadovat někam vaše data, smazat nebo zašifrovat data, rozesílat spam, těžit bitcoiny, odposlouchávat klávesnici a čekat na zadání heslo roota atd. Na to odposlouchávání klávesnice a zkoušení přihlášení má malware spoustu času, a kód nemusí být triviální.

    Pokud jde o samotné vlastnosti X11, tak tam je samozřejmě absence izolace X11 events mezi procesy běžícími v různém kontextu velmi snadno zneužitelnou dírou. Prakticky to znamená, že procesy běžící v jedné session pod různými účty nemáte oddělené, a jakákoliv argumentace oddělení o rolí restricted usera a roota pak padá.
    Wayland má být zpětně kompatibilní s X11, takže nečekám, že by problém vyřešil.

  • 13. 10. 2014 22:52

    M. Prýmek

    > jak jí poznám?

    Např. podle FIPS certifikace. Nebo nějakým jiným druhem ujištění výrobce, pokud se mu rozhodnte věřit.

    > a jakákoliv argumentace oddělení o rolí restricted usera a roota pak padá.

    Aha, vy jste to asi nečetl pozorně. Celá Xka jsou spuštěná pod uživatelem, který je speciálně určený k práci s podezřelým usb zařízením - tj. JINÝM uživatelem, než normálně používám k práci.

    > malware může provádět neplechu i pod restricted userem.

    Pokud mám X session (dočasně, po dobu vložení podezřelé flashky) puštěnou pod uživatelem, který nemá žádná práva a žádná data, tak nemůže provést neplechu žádnou.

    > podvržením USB síťové karty

    Podvržením USB síťové karty se poučenému uživateli nestane vůbec nic. Karta může udělat maximálně to, co tak jako tak může udělat kdokoli po celé internetové cestě mezi mnou a cílovým serverem.

    > Wayland má být zpětně kompatibilní s X11, takže nečekám, že by problém vyřešil.

    AFAIK u Waylandu každé okno simuluje jeden samostatný X server (každé okno zvlášť), takže tam tohle padá. Ale jak říkám, tuhle oblast moc nesleduju.

    Kromě toho ještě existuje fork Xek pod OpenBSD, tam nevím, jestli to není taky nějak speciálně řešeno.

  • 14. 10. 2014 0:36

    Lael Ophir (neregistrovaný)

    Ad FIPS certifikace - děkuji za tip. Koukal jsem na to, mohlo by to být řešení.

    Ad celá Xka jsou spuštěná pod uživatelem, který je speciálně určený k práci s podezřelým usb zařízením - to asi není moc praktické, zvlášť když podezřelé USB zařízení je prakticky každé.

    Ad u Waylandu každé okno simuluje jeden samostatný X server - potom by to rozbilo spoustu aplikací, které spoléhají na X11 events. Ale co jsem někde četl, není ve Waylandu ještě ani podpora clipboardu. Také na to nejsem expert, takže se necháme překvapit.

  • 14. 10. 2014 1:17

    M. Prýmek

    > to asi není moc praktické, zvlášť když podezřelé USB zařízení je prakticky každé.

    No právěže není. Podezřelá je flashka, kterou jsem si neprověřil z hlediska updatovatelnosti a zároveň jsem ji někdy strčil do podezřelého počítače. Takovou flashku prostě musím držet v karanténě = oddělená session jenom na to překopírování souborů, nic víc od ní nechci.

    > potom by to rozbilo spoustu aplikací, které spoléhají na X11 events.

    To nevím, co přesně myslíte. Samozřejmě na Waylandu nemůžu pustit normální window manager pro Xka. To je by design.

    > Ale co jsem někde četl, není ve Waylandu ještě ani podpora clipboardu.

    To je klidně možný, je to prostě work in progress... Mě osobně to vůbec netrápí, protože Linux mám jenom na notebooku pro takové to domácí brouzdání a nějaké technické zákroky v terénu, takže co se mě týče, jestli bude Wayland funkční za 10 let, tak je mi to fuk :)

  • 14. 10. 2014 3:38

    Lael Ophir (neregistrovaný)

    Ad podezřelá je flashka, kterou jsem si neprověřil z hlediska updatovatelnosti a zároveň jsem ji někdy strčil do podezřelého počítače - chápu že jako uživatel Linuxu máte trochu jiné bezpečnostní standardy, než většina populace. Bohužel nestačí že ochráníte sebe. Ono stačí mít v podniku jednoho uživatele, který strčí do počítače flashku od dodavatele, nebo na té své dá kamarádovi upirátěné filmy, jen na pět minut :). Nakonec Stuxnet byl dost zásadní průšvih, rozšířil se přes USB klíčenky, a ani nemusel přeflashovat firmware. BTW ten mechanismus infekce je u Stuxnetu celkem pěkný.

    Ad Waylandu nemůžu pustit normální window manager pro Xka - aplikace si mohou povídat přes X11 events. Například drag and drop je (nebo minimálně může být) realizovaný přes XDND. Když pro každý proces simulujete samostatný X server, spoustu toho rozbijete.
    http://www.newplanetsoftware.com/xdnd/
    http://en.wikipedia.org/wiki/X_Window_selection#XDND

    Ad jestli bude Wayland funkční za 10 let, tak je mi to fuk - mě se to osobně také moc netýká, ale X11 mělo dávno zahynout a být nahrazeno něčím rozumnějším.

  • 14. 10. 2014 10:46

    M. Prýmek

    > Ono stačí mít v podniku jednoho uživatele, který strčí do počítače flashku od dodavatele

    Ve firmách, kde o něco opravdu jde (banky apod.) jsou na používání médií už dávno politiky. Např. můžou říkat, že do počítače je možné strčit jenom schválené zařízení. A povoleno to má jenom člověk, který to nutně potřebuje k práci. Ostatním se usb porty prostě vypnou.

    A když se někdo přesto nakazí, no tak se prostě nakazí, no. Je to stejné jako když jednou za čas někdo klikne na přílohu LOVE-LETTER-FOR-YOU.TXT.vbs, to se prostě stává, síť se monitoruje a zlotřilé počítače automaticky putují do karantény. (Mimochodem, když už jsem u toho, to skrývání přípon, to Microsoft taky vymyslel báječně :( To je taky díra samo o sobě).

    > Například drag and drop je (nebo minimálně může být) realizovaný přes XDND.

    No ale Wayland je kompletně nový koncept a všechny tyhle věci tam jsou nebo budou implementovány jinak.

    > X11 mělo dávno zahynout a být nahrazeno něčím rozumnějším.

    Jak se to vezme. On je to bolehlav hlavně pro programátory - a to jenom ty, kteří dělají toolkity apod. Ostatním to může být celkem jedno, protože Xka fungují a používat se dají. I programovat se pro ně dá, když se obalí nějakým tím toolkitem.

    Já třeba mám na pracovním stroji FreeBSD, kde Wayland nebude buď vůbec, nebo o dalších 10 let později :) a nijak mě to netrápí, protože co potřebuju udělat, udělám krásně. Než zas znovu řešit nějaké mizerné drivery od výrobců, tak to raději mám po mnoha letech odladěný Xka, který dělají všechno, co od nich potřebuju :)