Názory k článku Bezpečnostní záplaty GrSecurity už nebudou k dispozici zdarma

Možná se pletu, ale domnívám se, že GPL2 takové politice nijak nebrání. GPL přece nevyžaduje, aby byl produkt k dispozici zadarmo, ani aby byl k dispozici komukoliv. GrSecurity může kód dodávat jenom platícím zákazníkům, ale nesmí vyžadovat žádnou další platbu navíc za poskytnutí zdrojáku (snad kromě nějakého minimálníhi manipulačního poplatku) a nesmí platícím klientům bránit v tom, aby kód dále šířili v souladu s GPL a to i zadarmo, pokud se tak klient rozhodne.

Na stranu druhou, brání jim něco dát si do své smlouvy se zákazníkem, že pokud tak učiní, poruší tak smlouvu a přestane být zákazníkem? Popotahovat někoho kdo to zveřejní po soudech nemohou, ale dotyčný si to může rozmyslet, pokud chce i další patche.

Brání jim v tom GPLv2 v bodu 6: „You may not impose any further restrictions on the recipients' exercise of the rights granted herein.“ Bez takového ustanovení by GPL moc nedávala smysl, protože by umožnila povinnosti stanovené GPL snadno obejít jejich zákazem v jiné smlouvě.

Nejsem právnička, ale vypovězení obchodní smlouvy se subjektem mi nepřipadá jako restrikce v právech daných GPL. Klient ten kód může ten kód šířit jak chce, bude mít stále právo kdykoliv si vyžádat zdrojáky verze kterou koupil, ale práva na další verze které vytvoří upstream mu GPLv2 neuděluje.

Podle mne to omezení je, protože záměr toho ustanovení by byl zabránit šíření toho kódu, a u zákazníků by to tak i působilo (ostatně proto by to ta firma dělala). Navíc si nejsem jistý, zda by takové ustanovení smlouvy nebylo diskriminační, resp. jestli by nebyla diskriminace, pokud by Open Source Security po vypovězení smlouvy odmítlo s daným subjektem smlouvu podepsat znovu, pokud by o to měl zájem.
Zajímavé by bylo, kdyby OSS poskytla slevu za to, že klient nebude patche šířit.
A taky si nejsem jistý, zda vůbec patche samotné (před aplikací) jsou vždy odvozeným autorským dílem. Dovedu si představit patch, který nahradí všechny výskyty volání funkce printf a nahradí je za volání funkce printf_hardened. Když nebude šířen formou diffu ale skriptu, dá se aplikovat na libovolný kód. A vlastně to ani nemusí být autorské dílo…

Čistě teoreticky by snad bylo možné mít ve smlouvě klauzuli, že pokud budou kód dále distribuovat, GrSecurity vypoví smlouvu o podpoře. Reálně by to bylo jasně průhledná snaha se vys*at na GPL a GrSecurity by si tak v komunitě okamžitě vysloužila tu nejhorší pověst. Je ale taky pravda, že jejich reputace minimálně mezi vývojáři jádra je už tak jako tak v bodě nula.

Já tedy GPLv2 chápu úplně jinak..

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

grsecurity vzal Linux (GPLv2), upravil jej (vzniká odvozená práce) a tedy jej podle 2b musí distribuovat pod GPLv2 *at no charge to all third parties*.. Přičemž explicitně zmíněná třetí strana je autor (autoři) původní práce a implicitně kdokoli, kdo má zájem.

Kdokoli může prodávat věci pod GPLv2 (i když je nevytvořil - pokud bych získal současný zdroják grsecurity, nazval to bettergrsecurity a začal to prodávat za poloviční cenu, jsem naprosto v právu) - zároveň ale musí vždy dávat k dispozici zdroják na požádání a zdarma. Pokud to nedělá, ztrácí právo kopírovat, modifikovat a distribuovat původní dílo a může být souzen.

tedy jej podle 2b musí distribuovat pod GPLv2
Nemusí je distribuovat. Může je distribuovat, a pokud tak činí, musí dodržet podmínky GPLv2. Může se tedy sám rozhodnout, komu je bude distribuovat – třeba jen těm, kteří mu zaplatí.

https://twitter.com/marcan42/status/724749571495075840

No, je to sice příklad trochu vytržený z kontextu, ale právě když jde o bezpečnost, tak to chce připomínky vývojářů jádra zapracovat, oni pak udělají i to code review. A ne udržovat vlastní patche, protože jsou tak zběsilé, že je nikdo z jaderných vývojářů reviewovat neche. A pak vnášet bezpečnostními featurami další chyby, právě proto, že kód je sice dobře míněný, ale špatně provedený.

Už vydaný kód bude možné dál distribuovat. Ale žádný další už zveřejněný nebude.

To mi právě není jasné. Když si ten kód koupím, měl by být pod GPL, takže jak mi chtějí zabránit ho zveřejnit, když budu chtít?

Mam podobne reseni, takze opet nazpatek na prvni policko...

Nastesti mne nelimituje CPU, takze ve hre zustava trebas Qubes.

OpenBSD nepodporuje, AFAIK, MAC, takze jako nahrada za GrSecurity to moc neni.

Jsem si docela jistý, že OpenBSD na Maců pojede: https://superuser.com/questions/528733/installing-openbsd-on-mac-mini-core-i5 někde na undeadly byla zmínka o zprovozňování i na Macboocích.

Pomoci pledge() se daji celkem rozumne sandboxovat procesy, ale musis s tim pocitat pri navrhu programu. Treba Chromium to pouziva.

Pokud opravdu potrebujes MAC, muzes se jeste podivat na HardenedBSD (v podstate FreeBSD s PaX featurami).

Na Ubuntu by řekl, zkus to s LXD. To žádnou podporu na straně CPU nepotřebuje. Plná virtualizace to sice není, ale izolace jmenných prostorů spolu s omezeními pomocí AppArmoru a SecCompu nabízí přinejmenším stejné zabezpečení proti nepřátelskému kódu, jako GrSecurity a firejail. Jestli to ale funguje na Archu, to nevím.

Buď je LXD v AUR, nebo se dá použít nspawn https://wiki.archlinux.org/index.php/Firefox/Tweaks#Run_Firefox_inside_an_nspawn_container

S tvrzenim o "prinejmensim stejnem zabezpeceni" bych byl opatrny. Grsec se hodne zpusoby snazi zabranit exploitnuti jadra. Namespacy jsou dost komplexni a jak pred par lety rekl Andy Lutomirski "if they're off you have a security problem, if they're on, you may also have a security problem" - snad je to dneska uz v lepsim stavu :)

Částečně je to pravda. Linux má skutečně tendenci věci řešit po microsoftsku: masivní inženýring a milion komplexních featur, kterým málokdo plně rozumí. Naproti tomu přístup OpenBSD, tj. mít co možná nejjednodušší a nejprůhlednější kód, aby bylo možné ho snadno auditovat, je sice lákavý, ale současně znamená, že OpenBSD nikdy nebude tak všestranný OS, jako Linux. Co je lepší záleží na konkrétních požadavcích.

Namespacy sice měly řadu porodních problémů (podobně jako jaily ve FreeBSD) ale v zásadě se to vyřešilo. Dneska se používají tak často a tak široce, i pro bezpečnostně kritické úkoly, že osobně neváhám k nim mít důvěru. Nějaký 0day se samozřejmě nikdy nedá vyloučit, ale totéž platí i o GrSec.

Firejail = namespaces + seccomp
LXD má totéž a k tomu navíc apparmor

To jistě, a i proto nečekám, že by to někdo nutně touto formou šířil. Ale v principu to může např. nějaké distro koupit, integrovat do instalace a šířit ve svých repozitářích.

Spíš než smysluplný obchodní model mi to proto připadá jako truc ze strany GrSecurity: když náš úúúúžasný kód nechcete do jádra, tak budeme najust kasírovat uživatele. Předchozí jednání GrSecurity naznačuje, že potřebná infantilnost jim není cizí.