Spíš by bylo na čase konečně ve výchozím nastavení zobrazovat zadávané heslo. Pokud uživatel opravdu musí zadávat heslo s nějakým publikem za zády (které mu určitě nevidí na prsty, že…), ať má možnost si ty hvězdičky zapnout. Nebo aspoň ať se zadaný znak na chvilku objeví a pak se změní na hvězdičku, když má někdo pocit, že by někdo heslo mohl zahlédnout z dálky.
Resp. zrovna u sudo by bylo vůbec nejlepší, kdyby to ve výchozím nastavení heslo vůbec nechtělo. Dá se to změnit v konfiguraci, ale to výchozí nastavení nedává smysl. Vede to jen k tomu, že je heslo náchylnější k prozrazení a uživatel si zvykne psát bez přemýšlení heslo pokaždé, když si o něj někdo řekne.
Nejlepší jsou GUI aplikace, které zobrazí políčko jenom pro heslo, žádný jiný input (a neumožňují jinam přepnout), neumožňují heslo zobrazit a nezobrazí, jaká je aktuálně nastavená klávesnice. Samozřejmě heslo musí obsahovat i speciální znaky a po třech neúspěšných pokusech se účet zamkne.
Jenže UAC je něco trochu jiného. Když budu mít na Windows uživatele se standardními právy, tak v UAC dialogu bude výzva k zadání loginu a hesla do jiného účtu, který to oprávnění má. To co myslíte patrně vy, že vyskočí jen výzva k potvrzení okna, funguje ale jenom ve chvíli, kdy ten uživatel už má práva administrátora (aka na linuxu se přihlásit jako root) a jenom to chce potvrzovat... což zní hezky dokud člověk nezjistí, že v tom systému existuje x jiných způsobům, jak vykonávat příkazy pod tím daným uživatelem s jeho oprávněními bez triggnutí UAC.
No jenže ten zásadní rozdíl je, že na Linuxu ten standardní účet má omezená práva, zatímco na Windows má práva plná. Pokud na Linuxu uživatel spustí něco nehezkého a to obejde sudo, tak to nebude mít efekt, protože na to nemá práva. Pokud ale ten samý malware tohle udělá na Windows (a spustí to třeba přes RPC, které je tam standardně povolené a spuštěné), tak se ta daná věc spustí s plnými právy. Takže ve chvíli kdy tam ještě nic cizího neběží, ale uživatel něco špatného otevře, je tohle ten moment, kdy tomu UAC nijak nebrání a je celé k ničemu... (ano, pokud uživatel otevře virus pro Win95, tak u něj ten prompt asi vyskočí :-) ).
Jenže z toho omezeného účtu na Linuxu se zavoláním sudo bez hesla dostanete na účet s plnými právy. Navíc bezpečnostní chyby eskalace práv z lokálního účtu na roota nejsou zas až tak výjimečné, a poměrně snadno lze takovou chybu vytvořit v systému i pouhou chybnou konfigurací. Podle mne je podstatně důležitější bránit se tomu, aby se pod uživatelským účtem nespouštěl škodlivý kód, než bránit škodlivému kódu v úniku z uživatelského účtu do administrátorského. Ostatně u většiny SOHO uživatelů je všechno důležité a citlivé dostupné pod uživatelským účtem, pod administrátorským účtem není nic zajímavého navíc.
Jako ano, sudo bez hesla taky zrovna bezpečné není. Nicméně sudo bez hesla není výchozí konfigurace, narozdíl od defaultní instalace Win, která toho uživatele jako admina udělá. Moje pointa v reakci na první příspěvek byla v tom, že UAC vypadá, jak je to dobře vymyšlené, ale ve skutečnosti je tam několik cest, kudy ho lze obejít i bez aktivní zranitelnosti v systému, takže je to celé jenom takové na oko, ačkoliv uživatel má pocit, že se nic nestane... zatímco když si aktivně půjde nastavit sudo tak, abych nezadával heslo, tak většinou tuším, jaké to může mít následky...
Bránit tomu, aby na té stanici nemohl běžet škodlivý kód, je šlechetná myšlenka, ale ta cesta je poměrně dosti obtížná, ne-li nemožná. V situaci, kdy na každý běžně používaný software vychází každý týden alespoň jedno CVE s nějakou RCE zranitelností se prostě může stát, že k tomu spuštění dojde i u těch lepších a poučenějších uživatelů. Realita s uživateli je nicméně ještě o dost horší a většina z nich jde vysloveně naproti tomu, aby k něčemu takovému došlo. A technicky tomu bránit je dosti komplikované - na Windows sice existuje něco jako software execution policies, ale pokaždé když po někom chcete, aby to nastavil, tak se začne dost kroutit... Protože nastavit to tak, aby to něčemu reálně zabránilo, ale zároveň ten počítač šel ještě používat, zvlášť když u tohohle systému se rozmohlo, že ty aplikace jsou naházené úplně všude kam je to napadne (včetně těch přímo od MS, které si spustitelné soubory taky cpou někam do AppData uživatelského profilu...) je prostě nadlidský úkol. A sice bych v tuhle chvíli rád řekl zlatý linux, kde nastavím noexec na /home a /tmp a ono to nic nerozbije... jenže ani tady to úplně neplatí, protože stejně dneska na každém systému je minimálně python... a vlastně nač python, když ten shell tam je stejně. Takže v situaci, kdy mi čtvrtina uživatelů klidně zkopíruje z web page do shellu string python -c "neco" jenom proto, že jim ta stránka slíbila, že se jim zvětší po odbouchnutí genitálie, je dost těžké s tím bojovat...
Ohledně admin práv - úplně nesouhlasím. Ano, data, ke kterým má uživatel přístup, to získá i bez admin práv. Nicméně pokud na tom stroji třeba jsou i data jiného uživatele, tak se to k nim nedostane, ale s admin právy ano. Stejně tak pokud si ten malware pokouší vytvořit nějakou persistenci, aby zůstal běžet i po restartu, tak s admin právy má mnohem větší pole působnosti, kde se může realizovat (včetně případných snah jak se vyhýbat nějakým antivirům nebo něčemu, co na té stanici může běžet). A s admin právy to taky může dělat nějaké další věci, co pod běžným uživatelským účtem nejdou - třeba poslouchat data na síti, posílat spoofované pakety a tak podobně. Tedy výrazně to zvyšuje šanci, že se to může dostat ještě někam dál, než na tu již napadenou stanici. Takže si úplně nemyslím, že když už selžu v té části, že se nepodaří zabránit spuštění závadného kódu, že je úplně jedno jestli to dostane nebo nedostane admin account. V autě jsou taky bezpečnostní pásy a poutáme se s nima, ikdyž je mnohem lepší vůbec nebourat.
Tipuju, že množství SOHO počítačů, které sdílí víc lidí, zároveň tam mají oddělené uživatelské účty, a zároveň nemají většinu dat sdílených, je mizivé.
sudo bez hesla si sice musíte explicitně nastavit, ale sudo s heslem původního uživatele je nesmysl – i když je to výchozí nastavení. Navíc je sudo s heslem spíš větší nebezpečí, protože prozradíte ještě svoje heslo.
Pro spuštění kódu po přihlášení uživatele má útočník dost možností i u běžného účtu. A pro napadení ostatních zařízení v síti použije útočník tu samou díru, kterou použil pro napadení daného počítače – k tomu nepotřebuje ani poslouchat na síti ani posílat podvržené pakety.
No sudo bez hesla ten příkaz prostě pustí a uživatel ani nezjistí, že to co se pustilo udělalo sudo. Pokud vyskočí prompt na heslo, tak je to nějaký red flag, že se tam děje něco divného. V tomhle případě bych řekl že je to ekvivalent toho, když UAC zobrazí to okno, které stačí odklepnout. Akorát sudo alespoň nejde obejít několika jinými validními způsoby, které nejsou považovány za security bug.
Jenže na napadení počítače nemusí nutně v tom softwaru být díra. Úplně stačí, že uživatel copy pastne random příkaz z webu do cmd liny a tím ti infikuje (což se očividně děje, viz některé postřehy z bezpečnosti, kde byly ty windowsí jako BSOD s tím že pro opravu je potřeba zmáčknout win+r, ctrl+v a enter. A tohle reálně v té síti stejně někdo udělá, nicméně pokud ten malware navíc dostane admin práva, tak tam následně může škodit více i u uživatelů, co by na tohle neskočili.
Pokud uživatel zkopíruje příkaz z webu a bez kontroly ho spustí, potvrdí pak UAC nebo napíše heslo do sudo. Ani jedno nebylo myšleno jako ochrana před kombinací „záškodník plus naivní uživatel“. Obojí (sudo i UAC) je ochrana pouze před chybou (omylem) uživatele nebo programu.
Pro znalé uživatele je dostatečný red flag to, že píšou sudo, nemusí pak ještě psát heslo. Pro neznalé uživatele není požadavek na heslo po zadání příkazu v terminálu žádné překvapení, protože to po nich chce heslo prakticky pokaždé, když něco spouští v terminálu. Myslím si, že dokonce spousta neznalých uživatelů považuje terminál za nástroj pro spouštění administrátorských příkazů, takže to, že přijde požadavek na heslo, považují za přímý důsledek toho, že spustili nějaký příkaz v terminálu. Pro ně terminál a sudo jedno a to samé jest.
BTW, o zbytečnosti hesla u sudo psali I autoři QubesOS: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-sudo.html