Příspěvky

256

Odkladiště / Re:Sledování CVE

« kdy: 22. 04. 2020, 01:35:04 »

Chcete se přihlašovat ke každému produktu ručně? Pokud ne, tak se bude hodit nějaký scanner, který identifikuje komponenty a pokusí se k nim dohledat známé zranitelnosti.

A konkrétní nástroj? Záleží na platformě. A situace se může lišit u zranitelností aplikací nainstalovaných v OS a u zranitelností 3rd party knihoven ve Vámi vyvíjené aplikaci.

Ale celkem univerzální je OWASP Dependency Check, případně asi i OWASP Dependency Track. (Navzdory podobnému názvu spolu až tolik společného uvnitř zřejmě nemají.) A teď je otázka i nasazení. Domácí použití? Správa tisíců počítačů? CI server?

257

Windows a jiné systémy / Re:Android - privacy app

« kdy: 12. 04. 2020, 23:05:31 »

Těžko data uchráníte, když zákeřná aplikace k nim bude mít přístup. Můžete se snažit zabránit exfiltraci dat, ale nejspíš taháte za celkem krátký konec provazu.

Ve Vašem případě se snažíte zabránit přístupu k Internetu jen někdy. Jenže každá rozumně napsaná aplikace bude nejspíš schopna taková data prostě uložit a odeslat později. A to se bavíme o aplikaci, která ani není psána s vědomím podobné „ochrany“ a autor aplikace se ji nesnaží nijak přímo obejít. Samozřejmě podobná ochrana může ve specifických případech pomoci, zejména pokud je potřeba data chránit jen krátkou chvíli, ale tady nečekám masový zájem.

A pokud připustíme, že se autor aplikace bude snažit podobná omezení obejít, nemusí pomoct ani aplikaci úplně odstřihnout od Internetu:

* Může se pokoušet data exfiltrovar třeba otevřením webové stránky ve výchozím prohlížeči, data předá do GET parametrů.
* Může napsat dvě zdánlivě nesouvisející aplikace, které si ve skutečnosti budou předávat data. Jedna bude mít přístup k citlivým datům, druhá k Internetu. Spolu to zvládnou…
* Různé covert channels. Když bude útočník ve vhodný okamžit fyzicky dostatečně blízko, může se snažit data exfiltrovat i neslyšitelným zvukem…
* Odesílat data lze někdy i alternativním způsobem. Aplikace s přístupem ke kalendáři může dát data do události a nastavit sdílení.

Ano, je to komplikovanější. Ale pokud chcete opravdu zabránit zneužití nějakých dat, v první řadě by je útočník neměl dostat. Zabránit exfiltraci může být náročnější, než to na první pohled vypadá.

258

Desktop / Re:Automatické spuštění okenní aplikace i bez přihlášení

« kdy: 04. 04. 2020, 22:40:03 »

Případně lze použít sudo a nastavit ho tak, aby šlo použít (třeba omezeně) bez hesla.

Bezpečnostní dopad je otázkou, ale oproti přímému použití roota se nejspíš nic nezhorší.

Koncepčně vidím problém v tom, že ta aplikace vypadá jako takový kočkopes. Pokud to dobře chápu, skládá se ze serveru (ten má běžet furt) a GUI (to se spustí až po přihlášení), ale ve skutečnosti jde o jeden proces, který se snaží obojí obsloužit zároveň. Jenže server by měl startovat co nejdříve a klient až po přihlášení, což dohromady nejde.

259

Software / Re:Kde najít přesnou formu spuštěného programu?

« kdy: 04. 04. 2020, 10:13:17 »

Ta varianta s xargs -0 a print "%q " je asi to nejpřesnější, co dostanete z běžícího procesu. Escapuje to parametry pro bash, ale samozřejmě to nezná přesnou původní formu ("foo bar" vs. 'foo bar' vs. foo\ bar). Nebudou tam různá přesměrování do/ze souboru (i když, to by se možná taky dalo nějak dohledat).

Například z příkazu:

tail ~/something | grep foo > bar

uvidíte zvlášť tail (s expandovaným ~) a zvlášť grep foo. Přesměrování do souboru bar by možná šlo dohledat jinde, v cmdline to nebude.

260

/dev/null / Re:Proč mapy.cz chtějí polohu?

« kdy: 03. 04. 2020, 09:33:22 »

V podstatě ze dvou důvodů.

1. Aby věděli, koho mají upozornit, když nahlásíte, že jste nakažen COVID-19.
2. Aby vás mohli upozornit, když někdo, s kým jste se potkal a měl také zapnuté sledování, nahlásí Seznamu, že měl COVID-19.

Samozřejmě na to nelze spolehnout ze spousty důvodů (omezené testování, omezené množství sdílí polohu, případy bez symptomů, nákaza se může přenášet přes kliky a poprskané obaly zboží v supermarketu, atd.). Rozhodně bych to nepovažoval za to nejdůležitější opatření, nejspíš i ta nejhorší rouška udělá větší službu. A je to (dobrovolný) zásah do soukromí. Ale pokud se s tím smíříte a nebudete z té aplikace vyvozovat přehnané závěry, tak když to nepomůže, nemělo by to uškodit.

261

Vývoj / Re:Segmentation fault

« kdy: 02. 04. 2020, 08:55:54 »

Dvě hypotézy:

a. Problém se týká práce se stackem, což Valgrind AFAIR nedetekuje. (Ono to ani není snadné u zkompilovaného programu. V případě heapu může nahradit dynamicky linkované funkce pro práci s pamětí, v případě stacku to asi nebude tak jednoduché.)
b. Problém se projeví jen pří souběhu více vláken. AFAIR Valgrind dost omezuje souběžnost vláken.

Zmíněný Helgrind může pomoci na kontrolu problémů se souběžností.

Kontrolu problémů na stacku by moho jít udělat pomocí managed implementace LLVM v GraalVM EE: https://medium.com/graalvm/safe-and-sandboxed-execution-of-native-code-f6096b35c360
* Vyžádá si to ale zkompilovat stejným způsobem i použité knihovny. Nedovedu od stolu vyhodnotit, jak jednoduché nebo náročné to bude v tomto případě.
* Samozřejmě se odchylujete od produkčního prostředí. To není ideální, ale asi se tomu úplně nevyhnete.
* Enterprise Edition je zdarma za určitých podmínek, možná by se tam vešel i tento případ. Rozhodně ale nejsem právník a tento komentář píšu sám za sebe, ne za svého zaměstnavatele.

262

Distribuce / Re:ZFS a Linux

« kdy: 22. 03. 2020, 20:09:00 »

Myslím, že není potřeba přelicencovat zdrojáky Linuxu. Co si vzpomínám, existují legálně moduly kernelu, které nejsou pod GPL, a dokonce jsou uzavřené. Má to tuším jakési omezení, co mohou non-GPL moduly volat, a co už ne. Důvod – pokud si dobře vzpomínám – spočívá v tom, že kernelový modul využívající tu omezenou podmnožinu funkcí je jistou analogií k procesu, který taky může (omezeně) volat některé funkce kernelu, aniž by musel být pod GPL.

263

Vývoj / Re:Segmentation fault

« kdy: 21. 03. 2020, 09:40:32 »

Chyba práce s pamětí může znamenat, že zapisujete do místa, na které zapisovat nemáte. Pokud máte štěští, nikdo jiný to míšto v paměti nepoužívá a bude to fungovat. Pokud máte smůlu, místo v paměti může používat i někdo jiný. To ale může vést ke kolizím, které nastanou poněkud později a v jiné části kódu, než kde je chyba. A na chování mohou mít vliv i víceméně nesouvisející změny, jako změna ze select na epoll – začne se používat jiný kus paměti, a najednou začne docházet ke kolizi třeba i ve funkci, která je na tom nevinně.

Valgrind toho umí najít spoustu, i když úplně neprůstřelný není. Ale takovéto nástroje jsou dobrým začátkem. Umí detekovat chyby často mnohem dříve, než by se reálně projevily. Často přímo na místě chyby.

Opatrnost na malloc – zase se to nesmí přehnat. Viděl jsem i kód, který slokoval data na stacku a předal pointer na ně. Pokud se ten předaný pointer používá i po návratu z funkce, která ho předala, je to problém. Bylo by věštěním z křišťálové koule, jestli je to Váš případ, ale může být.

264

Vývoj / Re:Jak funguje Java KeyStore?

« kdy: 21. 03. 2020, 09:20:59 »

JKS s prázdným heslem: Teoreticky to možné je, otázka je, jak to pobere která aplikace. Tuším, že to bere i hodnotu null pro JKS bez hesla. https://stackoverflow.com/q/23629246/228114

Private key je privátní klíč pro přihlášení. Ten nemůže být v truststore ale v keystore. Nejde o to náhodně převádět mezi sebou různé formáty souborů, ale musíte vědět, co (jaký obsah) kam patří.

+1

Navíc některé formáty (třeba zmíněný JKS) mohou obsahovat obojí. To pak ale tuplem znamená, že se nelze orientovat jen podle formátu.

Jinak pokud mas potiz s tim zadat cestu k JKS truststore, muzes ty svoje veci nacpat naprasaka do defaultni Java truststore, default heslo je "changeit"

To bych moc nedoporučoval, tím ovlivníte truststore i dalších aplikací. A s trochou nešikovnosti důvěřujete další certifikační „autoritě“.

A jeste je moznost, najdi si spoustec a pridej k jave commadline parametr -D se specifikaci techto properties:
javax.net.ssl.keyStore = /etc/myapp/keyStore
javax.net.ssl.keyStorePassword = 123456

* Asi spíš myslíte trustStore než keyStore, že?
* Přijde mi to jako menší zlo než globální trustStore, ale i tak to může mít vliv i na místech, kde nechcete. Záleží na situaci.

265

Software / Re:RDP na Linuxu s Wine - bude to fungovat?

« kdy: 20. 03. 2020, 18:20:48 »

Nejsem si úplně jist, jakou roli tam hraje to USB, ale je to asi to první, co bych ověřil. Když jsem to kdysi zjišťoval, Wine nemělo podporu USB, a obávám se, že stále nemá.

V případě Mono jsem zkoušel v rychlosti poGooglit, a našell jsem pár možností, jak tam rozjet USB, ale vypadá to, že jde spíše o specifické knihovny s jiným API, tedy ne něco, s čím by jela aplikace pro Windows bez úprav…

266

Hardware / Re:Malá popularita F2FS na flash pamětech

« kdy: 20. 03. 2020, 08:03:37 »

Něco jako TRIM jsem na microSD už viděl, jen se tomu říkalo nějak jinak. Ale s fstrim to fungovalo. Nečekal bych to na 10 let staré kartě, možná ani na 5 let staré kartě (i když z té doby už nějaké karty budou) a možná ani na té úplně nejlevnější dnešní kartě, ale třeba na A1 (a snad nejen tam) by to snad už mohlo být. Statistiku nemám, ale ani Vy žádnou u svého trvzení neodkazujete.

Proč se neprosadilo tolik F2FS – spekulace a vzpomínky na to, co jsem někde četl:

* Někde jsem četl, že to prý není tolik otestované, aby si to třeba výrobci telefonů troufli nasadit.
* Tuším, že tam po čase s fragmentací dost klesala rychlost čtení.
* S A1 asi klesla potřeba řešit F2FS.
* S podporou discardu taky.

267

Hardware / Re:DYI Plicní ventilátor

« kdy: 20. 03. 2020, 07:52:05 »

Vím, že je to trochu OT, ale jedna taková poznámka k rouškám a nedokonalým opatřením (konkrétní čísla berte spíše ilustračně):

* Někde jsem četl, kolik jeden pacient průměrně nakazí dalších lidí, bylo to mezi 2 a 3, počítejme 2.5. Bohužel nevím, jaké se to týkalo situace, doufám, že se to týkalo situace bez jakýchkoli opatření proti dalšímu šíření.
* Je-li toto číslo větší než 1, znamená to exponenciální růst.
* Je-li toto číslo menší než 1, znamená to exponenciální pokles nově nakažených. Nebo jinak, počet se začne s nějakou rychlostí otáčet k lepšímu. Byť se to ve statistikách objeví až se zpožděním.
* Mějme čtyři různá opatření, kde každé sníží riziko nakažení o 25 %. (Je tu trochu problematický předpoklad, že ta opatření budou fungovat na sobě nezávisle, ale dejme tomu.) To by znamenalo, že jeden nakažený nakazí něco pod 0.8 dalšího člověka (2.5*(1-0.25)^4 = 0.791015625), což už je nižší než 1.
* Opatření, které toto číslo sníží o 50 %, stačí dvě.
* Opatření, které toto číslo sníží o 75 %, stačí jedno.
* Čekat na imunizaci populace – to by znamenalo dost nemocných. Polovina populace zřejmě nestačí. Pak je tu
* Teda „stačí“ – samozřejmě menší průměrný počet nakažených znamená rychlejší zvládnutí situace a rychlejší konec opatření.

Co jsem tím chtěl říct – jakékoli nedokonalé opatření, které jen snižuje pravděpodobnost a samo o sobě nestačí, pomáhá, a může být tou „poslední kapkou“ v boji. Bohužel dopad ve statistikách neuvidíme ihned.

268

Hardware / Re:USB-C PD kabely

« kdy: 14. 03. 2020, 04:41:18 »

Jehla jde použít, bacha na zkrat. Na vypnutém zařízení to může být OK (i když, některé USB porty zůstávají napájené třeba kvůli podpořé nabíjení i při jinak vypnutém zařízení), za běhu bych spíše doporučil jiný postup. Snad cokoliv maléhpo tenkého nevodivého. Já obvykle vyšťaruju prach rožkem papíru. Klasický rožek obdélníkového papíru svírá úhel 90 °, což je dost, ale při přeložení podle osy úhlu (v případě čtvercového papíru to odpovídá i úhlopříčce čtverce) se dostaneme na 45 °, což jde použít snadno.

269

Distribuce / Re:Synchronizace OS - jde to vůbec ?

« kdy: 27. 02. 2020, 07:46:19 »

Úplně automatická synchronizace vždy znamená nějak vyřešit, co se má stát, když se na každém z počítačů jeden soubor modifikuje jinak. Což se může snadno stát, a pokud připustíme možnost běhu offline, zabránit tomu technicky nejde.

Klíčovou otázkou je taky, co všechno synchronizovat. Seznam nainstalovaných aplikací by neměl být problém. Asi nechcete úplně synchronizovat nastavení k specifickému hardware, možná ani nastavení obrazovek a jejich rozlišení.

Externí SSD může být řešení (a technicky řeší problém s modifikací na obou stranách – to se zde nestane), vidím tu pár „ale“:

* Rychlost – pokud bude připojené přes USB, přidá se tam latence. Nejspíš to nebude horší než HDD (aspoň dokud nebudete vytěžovat i jiné USB na stejném USB controlleru), ale může to být znát.
* Bezpečnost – vyžaduje mít povolený boot z USB.
* Konfigurace specifické pro hardware.

Další možnost je mít nějaké skripty, které udělají, co je potřeba, a ty si třeba verzovat v Gitu. Skripty by měly být idempotentní, tzn. pokud je spustím podruhé, nic se nestane. Změnu na obou stranách to řeší celkem rozumně (musel byste to udělat vědomě, a pokud to uděláte, Git to vyřeší nebo udělá konflikt a bude chtít zvolit řešení). Rozdílný hardware to taky řeší – prostě si budete sdílet jen to, co potřebujete. Lze na to použít jak speciální nástroje (např. Ansible), tak je možné si vystačit s obyčejnými Bashovými skripty. Ale vyžaduje to nějakou ruční práci.

Pak tu jsou nástroje na automatickou synchronizaci na pozadí jako Dropbox (centralizovaný) a Syncthing (decentralizovaný). Záleží, jak je použijete a co všechno tím budete synchronizovat. Nedoporučuju tím ale synchronizovat ani celé /etc ani nastavení běžících programů v domovském adresáři. Celkově bych na podobná řešení byl velmi opatrný a nevím, jestli bych to zde použil. Tyto nástroje na pozadí synchronizují soubor po souboru. S trochou smůly v případě synchronizace celého /etc nemusíte nabootovat (zvlášť pokud počítač vypnete v nevhodnou chvíli) a v případě synchronizace nastavení běžících aplikací můžete způsobit těmto aplikacím problémy nebo naopak vám tyto aplikace mohou synchronizované soubory zpátky přepsat.

Podobně dopadnete s rsyncem, akorát s o něco menším rizikem, pokud jej budete spouštět ručně, přestože si můžete částečně pohlídat, aby běžel ve vhodnou chvíli. Já bych to tak ale dělat upřímně nechtěl.

270

Odkladiště / Re:Sken všech veřejných domén

« kdy: 17. 02. 2020, 08:09:49 »

No, myslím, že OP má už dostatek záznamů na to, aby to nestíhal zpracovat. Zmíněné certificate transparency bude obsahovat všechny bezpečnost dobře funkční* weby na HTTPS. Vzhledem k tomu, že asi přes 3/4 provozu jde přes HTTPS, bude to asi významná část webu. Ano, přes 3/4 provozu není nutně přes 3/4 webů, ale otázka je, jak moc Vás zajímají stránky, kam prakticky nikdo nechodí.

Pokud chcete experimentovat s nějakým vyhledávacím algoritmem, máte nyní IMHO dost dat na to, abyste to bez větších investic do infrastruktury nezvládal zpracovat (doba indexování, velikost úložiště, datový tok, …). Můžete se k tomu postavit:

a) zaindexuju, co zaindexuju, pro experiment to bude stačit
b) omezit scope, například pouze na české stránky nebo na weby na doméně cz (i to je docela dost)

Upřímně si nemyslím, že byste byl schopen vymyslet lepší algoritmus, než jaký má celý Google. Neberte mě špatně, ale když si vezmete, kolik lidí na tom v celém Googlu pracuje, je to dost nepravděpodobné. I tak taková věc může mít smysl:

a) Na nějaké dost omezené skupině webů by se to s dobrým nápadem podařit mohlo. Pak bych ale vzal do úvahy tu skupinu webů již na začátku, tedy pří sbírání seznamu webů k zaindexování.
b) Může to být cvičení, při kterém se něco naučíte.

*) tím nemyslím weby s neplatným certifikátem