Příspěvky

196

Bazar / Re:Prodám Corning Thunderbolt 3 optický kabel, 50m

« kdy: 12. 07. 2022, 17:03:46 »

BTW: spadl mi kamen ze srdce, čirou náhodou jsem měl otevřený Preserve Log v Network Tabu v Dev Tools a zrovna udeřila pět let reportovaná chyba při odesílání příspěvku Litujeme přistup byl odepřen

stačí v klidu otevřít dev tools, dát f5, napíše to, že příspěvek už existuje, ale v network kartě mám samotný POST a textu příspěvku.

197

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 12. 07. 2022, 17:01:35 »

Možná by stálo za to se na to víc podívat. Udržovat AA profily není žádný problém. Může se stát, že díky striktnímu profilu aplikace po aktualizaci nenaběhne, ale v AA se to ladí velmi snadno. Já takhle funguju už roky a "náročné" bylo jen se to naučit (no asi den jsem tomu věnoval), pak jsou změny v pohodě. AA je fakt pěkný.

Ono jsou věci, které člověk sám optimálně neošéfuje (kvalita algoritmů, bezpečnost systémových aplikací atp.), jsou věci, které jsou fajn, když udělá sama apka (drop capů, sandbox atp.) a jsou věci, které nikdo neudělá líp, než Vy sám (právě ochrana dat v HOME a izolace aplikace), částečně proto, že to s sebou přináší jisté nepohodlí (nějaká "super fíčura" nemusí fungovat, webové aplikace prostě nevidí do dokumentů, protože tam prostě prohlížeč nesmí) a to nikdo neudělá by default, a taky je každý systém jiný a každý uživatel má data jinak. Představa, že se mi někdo univerzálně postará o 100% bezpečnost mého systému je naprosto naivní, ale když chci tomu pomoct, Linux ty nástroje má, Widle ne.

ono to bude přímo souviset s tím jaké aplikace používáš. Udržovat AA profily je určitá práce navíc a musíš na ní myslet a je to stejně jen řešení na půl cesty, nelze tím selektovat síťové komunikace, nelze tím snadno podchytit programy, které spouštíš poprvé, takže běžná práce je si vše spouštět v sandboxu a podle prvního chování si vygenerovat AA profil. Pak stačí jednou aplikaci spustit přímo nebo nepohlídat profil a máš bezpečnostní problém na světě. Jako nástroj pro servery, kde mám nějakou přípravnou fázi, testovací a produkční to je přijatelné, ale pro desktop? Není to zatím ono. Ano, také to používám, právě proto si nedokážu představit, že to někomu představím jako řešení.

Izolace aplikací v rámci jednoho účtu je na Mac OS nebo Windows řešena lépe, tam to ale zabíjí řada jiných chyb, na linuxu ty chyby nejsou, protože neexistují komponenty, které by je mohli obsahovat. Už jen to, že AA lze obejít přes eBPF je dost velká divnost v návrhu, ano, končí to deaktivací eBPF.

AA nebo Selinux jsou velice dobré nástroje, o tom žádná, ale pro desktop, kde si chci v prohlížeči pouštět videa, nahrávat soubory, programovat v IDE, kompilovat programy, scriptovat v pythonu, instalovat conda balíčky je to dost komplikované a nepřipravené, aspoň teda pro mě.

198

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 12. 07. 2022, 15:25:44 »

Ale hlavní problém je, že to vyžaduje poměrně expertní úroveň, abych systém měl bezpečný, pak stejně stačí chyba a nemám ho (udržovat AA profily při aktualizaci je docela oříšek). Tohle asi není dlouho udržitelný postoj.

Stavět objektivní bezpečnost na subjektivní důvěře ve své schopnosti je sám o sobě klam a nemůže vést k objektivně zabezpečnému systému.

Kvalitu Windows nebo Mac OS neobhajuji, jen tvrdím, že má nástroje, které linux a *BSD zatím nemá. OpenBSD jde ale jinou cestou a z principu to není špatné, ve výchozím stavu nabízí daleko více neže freeBSD nebo linux obecně.

Primárně pracuji na linuxu a s linuxem, ale to neznamaná, že neznám jeho slabé stránky a bezhlavě ho budu obhajovat.

199

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 12. 07. 2022, 13:53:12 »

pokud jde o desktop, tak bezpečnost linuxu a ani *BSD není vysoká, chybí jim totiž transparentní možnost jak oddělit práva procesů spuštěných pod stejným uživatelem.

Co je to za nesmysl? Co Apparmor, SELinux, FireJail etc. Nic? Co z toho mají widle, prosím? Tam je škodlivý SW hned v celým systému a nikdo tomu nezabrání. Když měl FF bug v PDF prohlížeči, všechna data byla na talíři. Já jsem se mohl jen pousmát.

ano, udělej si sám. Která z linux distribucí to má pro desktop připravené?

Mluvím třeba o obdobě ACG/CIG u Windows nebo KIP/KTRR u Mac OS. Linux má LSM (nad tím je postavený Selinux nebo apparmor), ale to je dost bezzubé, musíš mít připravené profily dopředu (kde je vezmu?), neumíš je měnit za běhu aplikace, pak stejně stačí eBPF, který obchází celé LSM. Projekty jako SARA jsou bez vývoje.

Měl jsem v ruce mod eset_rtp, to je také šílenost jak nesmyslně se snaží do linuxu na desktop přidat realtime ochranu, předávání dat do user space aplikace ke kontrole je hnus.

Jak linux zabrání, aby přes stejnou zranitelnost v FF neunikla data? Ptám se na výchozí instalaci a ne udělej si sám.

200

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 12. 07. 2022, 11:20:16 »

...

takze BSD ma nejake sytemove API, ktore mi umozni napisat bezpecnu aplikaciu? Napr ochrana pamete, sifrovanie, cert stor ako ma Windows? Ci zas nic ako na beznom Linuxe, kde chybaju prava pritupov na subory a procesy, ci lepsie zamkanie suborov?

těch mechanismů tam má celou řadu, např. poslední dobou se vše přepisuje na pledge(2) [omezený syscallů, je to v podstatě náhrada za privdrop  u roota] a inveil(2) [omezení fs volání].

Síla openBSD v bezpečnosti je za mě v tom, že na to jdou komplexně od podlahy, nesnaží se dělat rovnáky na ohejbáky, ale rovnou připravují i prostředí pro vývojáře, např. často špatně používanou funkci strcpy přepsali na strlcpy a omezily chyby, které způsobí sám vývojář. Ten systém je daleko transparentnější a přehlednější, stejná parta lidí řeší kernel u user space aplikace, vše má stejný layout, man page jsou aktuální a užitečné, makefile všude stejné, není to minové pole divností jako linux (vč. kernelu), nesnaží se za každou cenu zavádět nové funkce, když si nejsou jistí s důsledky (takový linuxový eBPF je ukázkový příklad toho, jak linux vývojáři se nechají přetlačovat a kašlou na bezpečnost). Pro víc informací mrkni třeba na wiki https://en.wikipedia.org/wiki/OpenBSD_security_features.

Rozhodně to ale neznamená, že pokud použiješ openBSD, máš bezpečnější systém než všichni ostatní, jen to znamená, že můžeš mít velice bezpečný systém s ne moc velkými náklady. Pořád je to systém, stavebnice a nikoliv hotový produkt a pořád tam sám můžeš spousty věcí zkazit.

201

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 12. 07. 2022, 09:39:32 »

pokud jde o desktop, tak bezpečnost linuxu a ani *BSD není vysoká, chybí jim totiž transparentní možnost jak oddělit práva procesů spuštěných pod stejným uživatelem. Ubuntu se to snaží dělat přes snap, openBSD to řeší/neřeší zároveň, ale proti ochranám, které mají Windows nebo MacOS, to je nesrovnatelné, musíš se na těch systémech chovat hodně odpovědně a případně si řadu věcí ošetřit sám (aneb kolik linuxů, *BSD systémů má ochranu konfiguračních souborů v ~, např. pro shell, tak aby tam cizí program/prohlížeč nemohl doplnit nějakou neplechu?).

openBSD nabízí asi nejlepší nástroje, jak připravit aplikace pro jejich bezpečný běh (sami sobě a i proti ostatním), ale jsou to jen nástroje, které musím umět použít a používat. Desktop se trochu odlišuje v tom, že ty programy vznikají za běhu, že spouštím cizí kód naprosto běžně a systém by na to měl reagovat.

Nemám moc zkušenost s *BSD na desktopu, nevyhovuje mi UI a ani nekompatilita se spoustou věcí, použím pouze na serverech.

202

Windows a jiné systémy / Re:skrytí ssid Android hotspotu

« kdy: 09. 07. 2022, 17:50:57 »

můžu se zeptat, k čemu to potřebuješ? Skrývání AP je tak absurdní funkce, že to nikdy nemělo existovat...

tak ono se to hodí, aspoň některé sítě neruší při výběru a třeba v budovách lze nechat viditelnou pouze veřejně dostupnou síť a ty interní ani nezobrazovat. Není to samozřejmě bezpečnostní funkce.

203

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 08. 07. 2022, 20:52:32 »

Z rodiny BSD mám macOS na MacBooku , ale moc mi ten systém k srdci nepřirostl. Linux mi vyhovuje víc.

to už bych tak ani nenazýval, Apple tam nenechal kámen na kameni a dneska je již jeho systém (Darwin) hodně vzdálený, co taky po 22 letech vývoje čekat.

204

Windows a jiné systémy / Re:Skusit BSD?

« kdy: 08. 07. 2022, 12:35:29 »

používám openBSD a freeBSD (headless, s desktopem zkušenosti nemám). A proč to zkusit? Přehlednost, čistota, jednotnost, man page na vše, dlouhodobě stabilní chování (žádné revoluce co ccca 10 let jak na linuxu).

Pracovně používáme hodně RHEL, tam má pocit, že každé 3 roky se učít od nuly, kolik tam je nových věcí, tajných zákoutí a přepsaných aplikací, to u *BSD se mi nestává, ta konzistence mezi verzemi je obrovská.

205

Sítě / Re:Diakritika hesla routeru

« kdy: 07. 07. 2022, 22:48:48 »

jakému routeru? Z principu lze zadat cokoliv, co dokážeš napsat, jen občas někteří výrobci uměle omezují, které znaky lze použít, takže odpověď je ano (spíše) i ne.

206

Server / Re:iSCSI - perspektivní protokol dnes (2022?)

« kdy: 07. 07. 2022, 16:50:37 »

Nesouhlasím s předřečníkem, že na NFS nelze provozovat DB. Třeba Oracle má přímou nativní podporu pro NFS a šlape to dobře. Teď ale migruji z NFS na iSCSI, protože nový storage neumí NFS. Jinak by mi to bylo jedno.
V testech vychází v některých situacích iSCSI rychleji, než NFS4.1
Každopádně iSCSI je naprosto běžné a není problém.
Zdar Max

ano, Oracle si k tomu udělal Direct NFS gateway, která mu záplatuje neduhy NFS, drží cache, řeší paralelismus a asynchronní IO. Provozovat databázi na NFS prostě není dobrý nápad z mnoha důvodů, o tom se asi přít nemusíme.

207

Server / Re:iSCSI - perspektivní protokol dnes (2022?)

« kdy: 05. 07. 2022, 11:58:21 »

modulům v ansiblu většinou moc neholduji, musím pak udržovat další závislost, rozbíjí se to mezi verzemi, raději si na tyhle věci buď píšou bash script jako wrapper nebo volám přímo command a detekuji si změny ručně. Většinou je takové řešení trvanlivější než zajišťovat na cílových strojích potřebné python knihovny.

S přechodem na python3 se nám většina modulů rozbila a bylo to dlouhé přepisování, teď to stejné zažíváme s python3.9, kde řada modulů nefunguje.

Dnes už na provisioning těhle věcí mám asi raději terraform a napsat si vlastního providera, pokud není. Lépe se to dlouhodobě udržuje.

208

Server / Re:iSCSI - perspektivní protokol dnes (2022?)

« kdy: 03. 07. 2022, 20:00:14 »

Vedle ještě stojí infiniband, asi ho mám nejraději, ale jsem tady skoro osamonec.

takže iser, jo?
IB taky mám, ale zatím jsem ho měl jako výpočetní síť pro MPI a občas NFS přes RDMA.

iSER je hodně silný a univerzální, já jsem odkojen ale jeho předchůzcem SRP a ten i pořád používám, je snažší na inicialiizaci a správu. Tu správu, ten přehled o celé síti, tu spolehlivost proti ethernetu, prostě úžasné. V infinibandu je dobře řešený multipathing, to v ethernetu je to malé peklo.

Hlavní důvod proč se mi to ale líbí je, že to dokážu bez problémů provozovat sám doma a stejně tak umím sám připravit síť pro zákazníky. V případě FC to je pro mě strašně obtížné, a SCSI nad TCP je prostě nemocná teta, zajistit tomu stabilní latency a šířku pásma není občas vůbec snadné. SCSI ale umím dotáhnout na klientské stanice, tam si FC ani IB nevrzne.

209

Vývoj / Re:Webova aplikace zabalena v Dockeru spolu s Databazi

« kdy: 03. 07. 2022, 19:44:46 »

já bych s tím slovem "obvykle" dával pozor. V enterprise prostředí se začínají objevovat krabicové SW, které se dodávají jako jeden velký docker container, spustí se to celé najednou a přidá tomu persistentní uložiště, pro obě strany to je velké zjednodušení.

Docker compose je sice fajn, ale v momentě, kdy třeba vyžadováno, aby veškerá komunikace mezi službami byla šifrovaně, upravovat docker compose skript a dodávat tam nějak pem/jks klíče už není zrovna snadné, pak tam vznikají problémy s formáty, divné chyby a celkově to zanáší problémy jak pro dodavatele, tak i pro zákazníka. To ani nemluvím o problém s autorizací, požadavky na auditování všech TCP komunikací atd. Monolitický docker image naopak má jen pár veřejných portů, které mohou snadno jít přes nějaký envoy či nginx, to si umí klient vyřešit sám a dodavateli to je jedno.

Takže bych s tím slovem "obvykle" šetřil, v některých trzích to totiž obvykle reprezentuje přesně tenhle stav monolitických obrazů.

210

Server / Re:iSCSI - perspektivní protokol dnes (2022?)

« kdy: 01. 07. 2022, 22:11:46 »

FC a iSCSI jsou tady vedle sebe, SAN běžně umí oba. FC ale potřebují celou speciální infrastrukturu na l2, s nástupem SDN a ceph se iSCSI daří daleko lépe, FC prostě nemůžeš moc řetězit přes switche, latence roste do nebes. Nové FC jsem už několik let neviděl (chápu, mám omezený vzorek). V např. prostředí českých bank nebo operátorů je více dat a provozu na iSCSI než přes FC.

FC na kubernetes nebo do cloudů je dost neprůchozí. NFS můžeš použít na nějaká statická data, ale provozovat databáze nebo OS na tom nemůžeš.

Vedle ještě stojí infiniband, asi ho mám nejraději, ale jsem tady skoro osamonec.

Třeba ale to vidíš jinak, nechci se o tom přít, každý jsme asi někde jinde, pořád to ale nic nemění na tom, že iSCSI mrtvé není. Tohle se často přes ansible nekonfiguruje, buď se to dělá ručně nebo jinými nástroji, ansible je na to dost nespolehlivý a pomalý.