Názory k článku
Linuxový malware je na vzestupu, počet infekcí vloni vyrostl o třetinu
-
Ano, existují. Na druhou stranu, jediný virus, na který jsem zatím při používání Linuxu narazil, byl pro Windows a ve Wine mnoho škody nenapáchal.
https://www.safetydetectives.com/best-antivirus/linux/ -
Ono to bude spíš tak, že útoky jsou úspěšné proto. že uživate někam zabrowsí, tam si infekční stránka řekne o práva, a uživatel nic zlého netuše práva dá.
Takže se začnou vyvíjet antiviry pro linux, jak se bue posouvat k mainstreamu, četnost poroste, a dopadne to tak, že uživatelé nějakého pofidérní distra si budou lebedit, jak je jejich obskurní systém bezpečný, protože nikomu nestojí za námahu. -
Ne :).
Sice se všichni posmívají Windows, jak je děravý, ale linux ani nemá tu vrstvu, která by děravá být mohla, to se to pak porovnává počet chyb.
Na linuxu kompletně chybí nějaké kernel api, které by stálo mezi aplikací a nějakou IO operací a kde by se mohla provést realtime kontrola a podle toho přístup ke zdroji odepřít nebo povolit. Existují pouze asynchronní cesty přes něco jako fanotify, sledování aktivity a případně zabití procesu, ale v té době již systém může být napadený.
Selinux, posix acl, chroot, oddělení uživatelé, iptables je vše co nám linux pro zabezpečení nabízí, žádná obdoba UAC neexistuje.
Provozovat desktop na linuxu je dost nebezpečné, složitě zabezpečitelné a je extrémně složité držet jednotlivé aplikace oddělené (docker, chroot, posix uživatel), pak to celé spustit nad xkami, které dovolí všem všechno. Nechci na linux házet špínu, ale v tomhle je extrémna slabý.
-
Ondřej KolínZlatý podporovatel
Pokud se to dotahne, tak by tohle mohl resit flatpak (portály), wayland a dalsi protokoly, pokud bude mezi vývojáři zájem řešit i bezpečnost a implementovat je do svých aplikací, ne?
-
to víš nebo v tom doufáš? :)
Dokud mohu zajistit, aby jednotlivé aplikace byly pod vlastním user id, orámovat je nějakým chrootem, udělat jim vlastní FW pravidla a zajistit IPC komunikaci bezpečně (tj. žádný dbus, žádný X11 server), jsem relativně v bezpečí. Co z toho je ale na linux desktopu k dispozici aniž bych musel praktikovat černou magii?
Nejblíže linuxu je asi android, však se podívej jak vypadá security architecture androidu, co vše tam má navíc a co vše není součástí linuxových distribucí, natož kernelu.
Na linuxu žiji, ale jeho desktop je trochu pozadu a bezpečností se to nedá srovnávat s Windows/MacOS. Naštěstí desktop nikdo neprovozuje, takže ty problémy nejdou vidět. Když už se ve firmách provozuje, víme jaké aplikace se budou potřebu používat a ty můžeme dostatečně zarámovat, selinux nám pomůže zakázat spouštět cizí kód a jsme ok, ale to není systém pro běžné použití uživateli.
-
Android je podla mna uplne iny pripad. Tam je dolezite (najme pre samotnu firmu co sa stara o vyvoj) aby to nebolo uplne opravene, lebo by to znamenalo obrovske vypadky ziskov. Firma, co sa ma starat o bezpecnostne zaplaty, a pritom zije z kradnutia osobnych udajov :) Tam jednoducho bezpecnost naozaj nie je priorita. Treba sa ale samozrejme tvarit, ze je... A ak sa v cistom androide aj chyba objavi a opravy, uzavrete google apky uz nikto prehladavat nebude.
-
Jan HrachStříbrný podporovatelAno, ale musíš to stáhnout a ten přístup tomu dát. A i když to uděláš a dáš tomu jenom nějaké malé přístupy, tak je celkem nepravděpodobné, že se to nějak vyláme a zneužije to i přístupy, které jsi tomu nedal. (samozřejmě, díry byly a budou, ale alespoň to není by design) Zatímco na Linuxu ti StarDict ukradne hesla z KeePassu (na Androidu bys mu nedal žádná oprávnění, když to chceš používat jenom tak, že do okýnka napíšeš slovo a ono to tam ukáže jeho překlad), Audacity odešle telemetrii (na Androidu bys tomu nepovolil síť), a vyhackovaný PDF prohlížeč ti vyowní zbytek systému.
Samozřejmě pak je na Androidu spousta jiného clustefucku, ale zrovna to popsané je tam udělané alespoň koncepčně docela dobře.
Ty věci v prvním odstavci nebyly coby-kdyby, vše uvedené se fakt stalo: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960, https://www.root.cz/zpravicky/audacity-bude-posilat-telemetrii/1071944/, https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html
-
Ondřej KolínZlatý podporovatel
Nastroje na to mame. Tohle presne muze resit flatpak. Je potreba aby vyvojari implementovali moderni API (portaly), preslo se na Wayland, nezadal se pristup k celemu FS apod.
-
ale to je pořád ten stejný problém, který se snaží řešit nedostatek Linuxu přes obrovské spousty virtualizace a snahy to oddělit, ale musíš kvůli tomu napsat stovky tisíc řádků kódu, přitáhnout si obrovské projekty jako xen a doufat, že tohle máš bez chyby, pak stejně řešíš security opravy skoro každý měsíc a stejně se nevyhneš problémům s low level implementaci jako např. IOMMU v podání xenu a jeho CVE-2021-28694 (staré pár měsíců).
Qubes také obnažuje nedostatečnost zabezpečení linuxu pro desktop, jinak by nemusel existovat. Zkoušel jsi ho ale používat? Dokážeš si představit, že tohle budou umět lidé ovládat?
Mně se líbí kam posunul OpenBSD jejich pledge a unveil, to je takový must-have základ, strašně jednoduše se to používá, postupně to implementují u všech jejich balíčků. Tohle udělat na linuxu s pomocí seccomp je asi nereálné.
Na linuxu takové projekty nevidím, flatpak, snap a jiné snahy jsou zatím spíše šílenost než generační posun, znáte jiné projekty, které jdou tímhle směrem? Na linuxu o desktop není zájem a ani nevidím, že by vývojáři ty problémy řešili.
-
a přitom mezi nimi je propastný rozdíl, myšlenka stejná, ale firejail vyžaduje setuid a běží to pod rootem (to není dobrý nápad nikdy), je to složitý a nepřehledný na konfiguraci, zatímco unveil je součástí samotné aplikace, kde jí vývojář dopředu řekne s jakými soubory může pracovat, zabrání se tím zneužití služeb, pokud služba má nějakou zranitelnost. V OpenBSD tohle postupně nasazují na všechny aplikace, firejail musíš ručně konfigurovat ty sám. Je tam obrovský rozdíl v tom záběru, na OpenBSD to používá automaticky, na linuxu firejail spíše vůbec a ochrana, kterou nepoužíváš, není moc účinná.
-
dakujem za zhrnutie. a ano viac-menej sa s tym da suhlasit (predovsetkym v zavere), na druhu stranu si neviem predstavit, ze by som openbsd pouzival ako hlavny desktop, takze to, co si mozu dovolit spravcovia openbsd - teda pridavanie konfiguracie pre vsetky baliky, si neviem realne predstavit pri linuxovom ekosysteme (stale hovorim len o desktope). na druhu stranu firejail uz nejake napisane profily pre casto pouzivane (?) programy ma, mozno by sa mu zisiel lepsi marketing a idealne aj nezavisly audit kodu.
-
@jose1711 na druhu stranu firejail uz nejake napisane profily pre casto pouzivane (?) programy ma
i "ne"pouzivane... ma jich celkem asi 1100 ;-)
https://github.com/netblue30/firejail/tree/master/etc/profile-a-l
https://github.com/netblue30/firejail/tree/master/etc/profile-m-zbtw: https://www.root.cz/clanky/firejail-zamknete-neposlusne-aplikace-do-vezeni-v-sandboxu/
-
-> ...
Zde cítím drobný rozpor:
Nastavení práv vývojářem je sice skvělé pro případ, že začne škodit např. některá knihovna z jeho aplikace, ale, jestli to správně chápu, neřeší ochranu uživatele, kdy vývojář škodlivou aplikaci cíleně vytváří, přičemž je otázkou, zda to po něm někdo bude ověřovat. Z tohoto pohledu je naopak žádoucí, aby nastavení práv aplikace řešil někdo třetí. -
samozřejmě, všechny porty, userland a kernelland změny procházejí code review a schvalovacím procesem. Maintener je pořád vývojář, vždy tam jsou další oči a často těch očí tam je spousta, vše je striktně veřejné. Pokud se bavíme o OpenBSD.
Nedokážu teď dohledat jestli se v OpenBSD někdy objevila záměrně zranitelná aplikace, stát se to ale může, stejně jako jinde
-
LSM je dost low-level api na registraci hooků do kernel kódu, je tam obrovský problém s kompatibilitou (viz ten eset_rtp), neumožňují snadno monitorovat vyšší akce a snadnou registrací aplikací jako je firewall, antivir aj, nebrání proti modifikaci kódu běžících aplikací a ani neumožňuje zabránit vložení kódu z venku a jeho spuštění. Aneb řečeno věci jako ACG nebo CIG z Windowsu jsou přes LSM těžko řešitelné (na macu to je třeba Hardened Runtime či KIP, KTRR atd.). Ano, leží tady v upstreamu S.A.R.A., ale to už je taky nějaký rok a nic se neděje. Opravdu Windows UAC není na linuxu přes LSM problém?
Nebo obecně věci jako control flow integrity, kernel data protection nejsou na linuxu vůbec, jak k tomuhle pomůže LSM? Pak je tady eBPF, což je geniální, umí totiž obejít LSM.
Nebo taková drobnost jako obrana proti keyloggerům, Windows i Mac se o to snaží, v linuxu nic.
Souhlasím s tím, že ani na Windowsu tyhle funkce nezabránily zranitelnostem, ale výrazně je omezily, to ale přece není důvod to nemít a tvrdit, že to není potřeba a že je to stejně jedno, takhle se přece k bezpečnosti systémů nechováme, ne?
-
Velky rozdiel je podla mna to, ze mac a windows su obidva platene softwari, na ktore ide financna podpora od konkretnych firiem. Linux ale robi vela ludi a firiem a robia veci podla urcitych priorit. Uvidime ale co s tymto spravi napr. Steam deck. Ak tam bude problem s virusmi, neverim ze niektora z vacsich firiem sa nepokusi antivirus tam dostat.
-
Jan HrachStříbrný podporovatel
> Velky rozdiel je podla mna to, ze mac a windows su obidva platene softwari, na ktore ide financna podpora od konkretnych firiem.
Tak to ty firmy asi podporují dost špatně/zvláštně, když tam jsou neuvěřitelné bugy typu pass the hash, bitlocker s klíčem v TPM a tak. Nebo malware na USB které ze sebe udělá klávesnici, to je nedořešené na Windows i na Linuxu, jenom na macosu na to AFAIK něco je. (ano, na Linuxu se to dá nějak magicky naskriptovat aby se USBčkové HIDy whitelistovaly) Ale předřečník má pravdu v tom, že zrovna izolace aplikací na desktopu je na Linuxu a několik dalších konkrétních věcí jsou dost tragické. Nebo třeba aplikační firewall prostě neexistuje (opensnitch je strašná bolest nastavit a jde triviálně obejít).
18. 1. 2022, 23:34 editováno autorem komentáře
-
Jan HrachStříbrný podporovatel
> a snadnou registrací aplikací jako je firewall, antivir aj, nebrání proti modifikaci kódu běžících aplikací a ani neumožňuje zabránit vložení kódu z venku a jeho spuštění
Jak tohle funguje? (Windows bohužel vůbec neznám) Takhle jak jste to napsal to zní jako NX/DEP, ale určitě to musí být něco víc.
-
Arbitrary code guard (https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/exploit-protection-reference?view=o365-worldwide#arbitrary-code-guard), DEP/NX tady je od Vist, dneska ty techniky jsou již dál.
No a na linuxu mně např. Selinux nezabrání použít mprotect(2). Teda má flag execmem, ale to způsobí poměrně značnou kaskádu dalších nefunkčností, on Redhat ví, proč to je vypnuté. Ok, mohu si udělat LSM hook, ale pak začnu řešit, že potřebuji kontextové informace a že všechny syscally jsou strašně nízkoúrovňové. Ta příprava na straně Linuxu není dobrá.
Pokud jde o tu registraci, např. na macu je Socket Filters, zastřešuje řadu volání jednoduchým api. V linuxu na to měl být eBPF, ale zatím má díru vedle díry.
-
Jan HrachStříbrný podporovatel
> Teda má flag execmem, ale to způsobí poměrně značnou kaskádu dalších nefunkčností, on Redhat ví, proč to je vypnuté.
Aha, takže to je na straně aplikací, že potřebují executable alokace, i když by nemusely (a nikdo to tam z jejich Windows verzí nenaportoval aby to chodilo)? Na co to potřebují? Pamatuju si, že se před pár lety řešilo, že nějaká knihovna vyžadovala executable stack a protože na ní všechno záviselo, tak pak mělo všechno úplně zbytečně executable stack, to bude něco podobného?
-
ano, je pak potřeba samozřejmě upravit aplikace, jeden z mnoha pokusů https://bugzilla.redhat.com/show_bug.cgi?id=1802479
Windows si tím marastem nekompatibilních a padajících aplikací prošli, trvalo nějakou dobu než se vývojáři naučili to dělat jinak. Linux to asi čeká, chce-li uspět v desktopu (potřebuje to?), pro servové použití jsme schopni držet laťku i s existujícími nástroji.
Ale dokud se bude bezpečnost brát povrchně jako u flatpaku, daleko se to nedostane (https://flatkill.org/2020/ - ani k dnešnímu dni výtky nejsou vyřešeny).
-
Jan HrachStříbrný podporovatel
Ta kontrola je na základě procesu a cesty (to pak dělá AppArmor nebo SELinux), nebo nějaký custom program (co má dělat?)? Nejde custom program realizovat hooknutím syscallu přes eBPF? https://blog.yadutaf.fr/2016/03/30/turn-any-syscall-into-event-introducing-ebpf-kernel-probes/
Že jsou Xka tragédie souhlasím, snad bude brzo použitelný Wayland. Zlepšuje se.
-
LSM ale k api (application programming interface) má daleko, poskytuje možnost si na jednotlivá označená místa vložit volání vlastního kódu, spíše bych to nazval jako framework k injectování kódu. Přes LSM řešit takovou jednoduchou věc jako povolení pro aplikaci číst konkrétní soubor nebo komunikovat s konkrétním souborem je na pěkných pár desítek hooků a pár tisíc řádků kódu. Pak stejně zjistíš, že tam jsou věci jako overlayfs, které řadu věcí řeší po svém a obchází.
Podívej se např. na Socket Filters na mac os, tak má vypadat api.
-
V takovém případě je tu AppArmor (založený na LSM). Ten má vlastní API a některé aplikace jako např. Chrome ho používají. Pokud chcete zakázat aplikaci přístup k souboru, to se dá v AppArmoru udělat deklarativně velmi jednoduše.
Neříkám, že to je ideální a že není co zlepšovat, ani že žádný jiný OS nemá nic lepšího. Ale není pravda, že by Linux nic takového neměl.
-
Já spíše ale mluvil o API pro antiviry a jiné ochranné SW, které by se do systému mohli registrovat a dělat filtraci podle svých pravidel, ty postupně aktualizovat i za běhu aplikací. U AppAmoru tohle moc nejde uskutečnit, ty pravidla třeba nelze měnit bez restartu aplikace. Nemluvě o dost nešikovném návrhu, kdy ho lze obejít hardlinky (nebo přímo přistupovat na soubory přes inode) a dostat přístup k chráněným souborům.
SElinux, AppArmor znám, používáme je k zabezpečení serverů a je to dneska už taková povinnost, ale také vidím, že tyhle nástroje na zabezpečení linuxového desktopu (nebo obecně single user modu jako se to používá v IoT) jsou nedostatečné a neumí jednotlivé aplikace od sebe odstínit, efektivně jim zabránit přistupovat na různé zdroje a komunikovat mezi sebou. Linux ani nenabízí snadnou možnost, jak to udělat aplikací třetí strany a o tom byl přesně můj příspěvek. LSM je na úrovni vlastního forku kernelu, to se nedá označit jako snadná možnost.
Teď jede velká vlna BI, narážíme také na problémy jak vlastně izolovat a zabezpečit potenciálně nebezpečný kód, který si analytici spouští ve svém Notebooku či jiném interaktivním prostředí. Ten problém je stejný.
-
mno a o tom mluvím, Eset má Endpoint Antivirus for Linux, ten používá vlastní kernel modul eset_rtp (služba oaeventd), který prívě tu mitigaci jednotlivých volán řeší a skenu za běhu, jenže musí jít dost low level.
Pak je tam ale třeba služba sysinfod, která asynchronně skenuje nová zařízení (primárně flash disky), protože to opět neumí dělat přímo.
Je s tím ale dost problémů, uvazuje tě to na konkrétní verze podporovaných kernelů nebo končíš v podobných srandách https://github.com/andrascz/eea-eset_rtp-patch-linux-5.10
To jen potvrzuje co jsem psal, Linux na to není připravený a tu podporuje nemá.
-
Pro Linux je řešení několik.
Klasický AV nemá víceméně smysl, protože jádro běžného AV chytá všechno možné, ale převážně to, co nakazí Wokna. Tzn. pokud tam nainstalujete klasický AV tak jen kvuli tomu, aby to skenovalo příchozí soubory a tyto tak nenakazily jiné Windows PC v síti (např. pro upload souborů do webových služeb, e-mail servery apod.). Je tam k tomuto k dispozici open-source ClamAV a LMD.
Na Linux se doporučuje jako ochrana před škodlivým kódem hardening, ten snižuje pravděpodobnost úspěšného napadení. Podpořit to můžete třeba lynis-em, který vám zkontroluje stav hardeningu dle nějakých pravidel.
Existují nástroje pro skenování integrity systému AIDE, Tripwire apod., které dokáží detekovat změny v systému, které může malware způsobit, a tak rozpoznat jeho přítomnost.
Existují i on-demand skenery/antiviry pro unix jako je rkhunter, chkrootkit. Ty detekují nějaká známá zadní vrátka, to umí snad i lynis.
Jinak jak je psáno výše. Není něco takového jako je na Woknech, protože má to nemalý overhead, a na to množství malware pro Linux co existuje/vzniká to nemá komerční smysl ani vyvýjet ani nasazovat a výše zmíněná řešení by měla problém dostatečně eliminovat.
-
Jan HrachStříbrný podporovatel
Co vlastně takový antivirus dělá? Buď detekuje signatury známých exploitů, což může ochránit prvních pár hodin mezi vypuštěním 0daye a vydáním opravy toho programu (jsou signatury vydávány rychleji než opravy?), nebo se to snaží uhádnout nějak heuristicky (funguje to? párkrát jsem se na to tady a na abclinuxu ptal a nic jsem se nedozvěděl), třeba spojeně s nějakými imunizacemi heapy, na což nějaké nástroje v Linuxu jsou. Nebo ještě něco dalšího?
-
Máme antiviry ve firmě plošně. A mají i verzi pro linux, tak jsme si to my linuxáci nainstalovali. Žere to 1,5 GB soustavně. Hnus fialovej. A ani to nedá vědět, když to něco strčí do karantény. Protože všechno nového zkompilovaného je pro antivir podezřelá věc.
(P.S. jo jasně, 1,5 GB nezní jako moc, když teď všichni mají hromady RAM. Ale já mám jaksi tendenci využít všechnu RAM na testy výpočtů předtím než jdou na superpočítač. A zas drbat se se všema měřícíma a testovacíma strojema a navyšovat jim RAMku, to je opruz, hlavně v případě kdy ty počtače fungujou roky bez problémů a na systémy co dobře jedou se mi nechce šahat.)
