tl;dr (1) najlepszy system bezpieczeństwa #
kernel i programów dla #
linux czyli #
grsecurity
nie będzie dalej rozwijany (2),
ponieważ autor nie dostaje kasy a nawet nie dostaje z powrotem kodu GPL od firm które go używają (3).
(4) Może my ("programiści z Polski" ( ͡° ͜ʖ ͡°) ) damy radę zrobić "kickstarter" aby dalej rozwijać projekt?
1)
//grsecurity.net/ to najlepszy i jedyny w swoim rodzaju system który modyfikuje kernel Linux czyniąc z niego naprawdę bardzo odporny system.
Odporny nawet na nieznane ataki 0-day.
Nawet root nie może zhackować maszyny na której pracuje (przy dobrej konfiguracji)
Nawet przejęty sterownik kernela nie może przejąć maszyny (uszkodzić reszty kernela - lub ma to bardzo utrudnione).
Implementuje ponad 30 świetnych ulepszeń, np zablokowanie pisania do kmem i ioport aby w razie exploit kernela i tak nie mógł on modyfikować pamięci kernela i przejąć maszyny, losowe ułożenie wątków w pamięci aby było trudnie realizować exploity i wiele innych.
2)
Będzie on nie dostępny za 2 tygodnie. Po 14 latach rozwoju autorzy mają dość problemów z sponsorami i brakiem finansowania.
Dokładny zakres blokady:
- kernel w wersji testing będzie dalej wydawany, nie jest tak do końca źle... chociaż, wersje stable są z pewnością lepsze
- kernel Mempo (
//deb.pl.mempo.org/ ) będzie musiał więc przeskoczyć nagle na wersję testing.
- skomplikuje to bardzo plany wprowadzenia grsecurity np do Debiana
- Hardened Gentoo pewnie dalej da radę
- kernel stable (ten dobry)
będzie dostępny dla sponsorów którzy płacą (rozumiem że kod od razu "wyleakuje") chyba że chcą tylko dystrybuować binary ale nie sądzę bo nikt poważny tego nie zaakceptuje przecież.. więc niby kod "wyleakuje" ale na pewno skomplikuje to wiele rzeczy w procesie wydawania/używania grsecurity
3)
Jak napisali w pełnym oświadczeniu
https://grsecurity.net/announce.php (kopia poniżej - jako archiwum)
Powodem jest to iż
- pracują od 14 lat
- jest to świetny system, szeroko używany przez wiele korporacji w tym embbed
- korporacje od embbed nie dały nigdy ani grosza na grsecurity
- korporacje od embbed nawet nie oddają kodu na GPL (np swoich zmian do kodu grsecurity)
- oczywiście oni pozywają ich i walczą z nimi, ale to są koszty prawnicze rzędu wielkości 20,000$ jednorazowo a sprawy ciągną się miesiącami czy latami
4)
Kick starter?
Polscy (między innymi) programiści tworzący Mempo - czyli grsecurity + narzędzia security/darknet spakowane dla
Debian, od dawna planowali jaką kampanię kickstarter aby zrealizować swój projekt (na razie on istnieje ale w zakresie głównie tylko samego kernela, a do zrobienia jest wiele innych ciekawych rzeczy).
Wykonaliśmy ponad 140 wydań kernela grsecurity dla Debian, w ok. 500 commitach git (
https://github.com/mempo/deterministic-kernel/ )
Zastanawiamy się nad kampanią kickstarter aby zebrać fundusze niezbędne do:
- finansowania grsecurity jako sponsor (zgaduję że oczekują czegoś rzędu min 1000$/miesiąc, dowiemy się)
- dalszego rozwoju grsecurity+debian budowania pakowania podpisywania testowania wydawania kernela
- utrzymanie serwerów, repozytorium itd
- wydania profili RBAC które chronią każdy ważny program przed wykorzystaniem w razie exploit (blokują mu dostęp do plików, procesów, sieci, operacji itd)
- rozwojem wygodnych rozwiązań virtualizacji aby jednym kliknięciem odpalić np przeglądarkę w VM odizolowaną do systemu. W tym wsparcie TAILS, tor
- integracja bezpieczeństwa sieciowego: tor, i2p, freenet, cjdns, vpn
- dopracowanie ochrony kluczowych programów: firefox (domyślnie jest dość niebezpieczny np błędy w javascript), tor browser bundle, klient email, klient IM, klient IRC, bitcoin, namecoin, inne coiny w tym monero-coin (anonimowy coin)
- wydanie instalacyjnego .iso (obecnie instaluje się Mempo już na założony system Debian - ta opcja też będzie zachowana dla wygody)
Fundusze
Zgaduję bardzo wstępnie (muszę zapytać wszystkich innych oraz naszego wydawcę) iż powinniśmy zebrać około może 50 - 200 tysięcy $ aby to miało sens poważnie się tym zająć (bo potrzeba sporo dla samego Grsecurity i to na z 2 lata na początek, a sama praca wymaga programistów którzy znają tą wąską tematykę więc trzeba by ich sensownie opłacić, do tego grono testerów in-house itd).
A akcje np na Kickstarter to by były opcje wpłacenia pewnie typu 5$, 10$, 50$, 100$ (i więcej) - od podziękowania itd, przez koszulki i takie tam - po np czas pomocy naszych programistów w konfiguracji czego byś potrzebował w zakresie działania z grsecurity.
** Mint, gotowy komputer, itd **
Oprócz wersji Debian był też pomysł na wersję dla Mint - aby bezpieczeństwo było jeszcze wygodniejsze dla każdego, dla szarego człowieka.
Była też idea sprzedaży gotowych bezpiecznych komputerów:
dokładnie dobranych pod bezpieczeństwo, konkretne modele płyty głównej itd, jakiś w miarę otwarty BIOS gdyby się dało, karta Intel (dla serwerów - ale jak ktoś potrzebuje Radeon to też będzie opcja. Nvidia jest do duszy jeżeli chodzi o bezpieczeństwo więc raczej nie ma to sensu).
Jak myślicie, ktoś z Was lub znajomych byłby zainteresowany takim na poważnie zabezpieczonym systemem?
Kopia oświadczenia (archiwum)
Important Notice Regarding Public Availability of Stable Patches
August 26, 2015
Grsecurity has existed for over 14 years now. During this time it has been the premier solution for hardening Linux against security exploits and served as a role model for many mainstream commercial applications elsewhere. All modern OSes took our lead and implemented to varying degrees a number of security defenses we pioneered; some have even been burned into silicon in newer processors. Over the past decade, these defenses (a small portion of those we've created and have yet to release) have single-handedly caused the greatest increase in security for users worldwide.
While a project maintained in our free time, we always tried to accommodate the widest userbase. One outcome of this has been the maintenance of not just one but two kernel patch series, stable and test. The stable patch series follows an older, actively maintained kernel with lower volatility. Applicable security fixes, both those with CVEs and those silently fixed upstream, are continuously backported by us to this series on a near-daily basis. The test patch series on the other hand has always followed the latest upstream Linux kernel, containing more volatile code and more experimental forms of some grsecurity features.
We first supported both the 2.4 and the 2.6 kernel series. Once 2.4 outgrew its usefulness (mostly due to distros at the time simply failing to boot with older kernels due to glibc requirements) we next chose 2.6.32 as our long(er) term supported stable kernel. Around that time, we realized that the growth of our own codebase and the rapid pace of upstream development put us at odds with their new development model. Much more testing, validation, and development needed to be performed at more frequent intervals, requiring more of our already limited free time. Thankfully, our calls for sponsorship were answered and we were able to continue working on maintaining sometimes not just two but three kernel series at the same time (starting with 2.6.32 and 3.2 as the stable series then moving to today's 3.2 and 3.14 stable series). Our stable series have existed solely due to the financial support of our sponsors.
So far so good, but why did we tell you this story? It turns out that not everyone played nice, in particular several very large companies in the embedded Linux world who have gone beyond simply taking advantage of our work. Not only has the entire embedded industry as a whole not contributed a single dime toward our continued development and maintenance (despite our work being critical to the security of the millions of devices using our code: streaming media players, credit card processing systems, etc), the companies we've identified have actively violated the GPL and even our trademark. These transgressions have continued despite their awareness and our legal action.
In the past year alone we've spent thousands of dollars on legal fees challenging the embedded Linux industry, each instance being unnecessarily dragged out over several months. Since our lawyer has advised us not to mention the companies by name, I will describe in general terms the most recent situation that began in May 2015 and concluded this month that broke the camel's back. A multi-billion dollar corporation had made grsecurity a critical component of their embedded platform. This in itself isn't a problem, nor is it necessarily (albeit extremely unwise) that they're using an old, unsupported kernel and a several year old, unsupported version of grsecurity that they've modified. This seems to be the norm for the embedded Linux industry, seemingly driven by a need to mark a security checkbox at the lowest cost possible. So it's no surprise that they didn't bother to hire us to perform the port properly for them or to actively maintain the security of the kernel they're providing to their paid customers.
For the past 14 years, we have been the benchmark of high security standards, prompting us in 2011 to protect that reputation by formally registering the grsecurity trademark. The aforementioned company has been using the grsecurity name all over its marketing material and blog posts to describe their backported, unsupported, unmaintained version in a version of Linux with other code modifications that haven't been evaluated by us for security impact. Simply put, it is NOT grsecurity – it doesn't meet our standards and at the same time it uses our brand and reputation to further its marketing.
They are publishing a "grsecurity" for a kernel version we never released a patch for. We provided evidence to their lawyers of one of their employees registering on our forums and asking for free help with backporting an EFI fix to their modified version of grsecurity based off a very old patch of ours (a test patch that wasn't even the last one released for that major kernel version). The company's lawyers repeatedly claimed the company had not modified the grsecurity code in any way and that therefore all the references to "grsecurity" in their product were therefore only nominative use of the trademark to refer to our external work. They would therefore not cease using our trademark and would continue to do so despite our objections. This final assertion occurred three months after our initial cease and desist letter. They also threatened to request "all available sanctions and attorneys' fees" were we to proceed with a lawsuit against them.
At this point we had spent thousands in legal fees for this specific case, so I reached out to the community at the time with a brief explanation of the problem to see if anyone knew of a trademark litigation attorney that would be interested in taking the case on a contingent fee basis. There were no replies, and our own lawyer's efforts at finding a trademark expert only resulted in finding someone who would analyze the case at a cost well above everything we had already spent: money we don't have, and money that could be better spent on development and research. We have little chance to remedy the situation through legal action against a multi-billion dollar corporation with a huge legal team, the capability to drag out the case for years (much like they dragged out our C&D request), and ability to outspend any adversary.
This announcement is our public statement that we've had enough. Companies in the embedded industry not playing by the same rules as every other company using our software violates users' rights, misleads users and developers, and harms our ability to continue our work. Though I've only gone into depth in this announcement on the latest trademark violation against us, our experience with two GPL violations over the previous year have caused an incredible amount of frustration. These concerns are echoed by the complaints of many others about the treatment of the GPL by the embedded Linux industry in particular over many years.
With that in mind, today's announcement is concerned with the future availability of our stable series of patches. We decided that it is unfair to our sponsors that the above mentioned unlawful players can get away with their activity. Therefore, two weeks from now, we will cease the public dissemination of the stable series and will make it available to sponsors only. The test series, unfit in our view for production use, will however continue to be available to the public to avoid impact to the Gentoo Hardened and Arch Linux communities. If this does not resolve the issue, despite strong indications that it will have a large impact, we may need to resort to a policy similar to Red Hat's, described here or eventually stop the stable series entirely as it will be an unsustainable development model.
Respectfully,
Brad Spengler & The PaX Team
Komentarze (39)
najlepsze
To co "programiści z Polski" ( ͡° ͜ʖ ͡°) możemy zrobić, to paczkować ten kernel dla Debiana, budować system dostosowany do pracy z nim (na bazie Debian, ew Mint itd), testować, dobrać sprzęt.
A teraz dochodzi nowy temat czyli
@mati75: może jakąś śladową część. Innowcayjne pomysły tworzone przez grsecurity ostatecznie trafiają nawet do kernela vanilla (tak po 5-10 latach :)
Wykop to nie miejsce na to, siła tutejszej społeczności polega na tym, że mogą co najwyżej zatruć życie jakiemuś
@BluRaf: cóż trzeba się przyzwyczaić że hobby kosztuje. Wędkarze nie mają problemu zapłacić za wędki, modelarze za modele itd.
Więc czemu tutaj miałoby być inaczej?
I to nie 50 złotych bo koszty prawnej obsługi zjedzą więcej niż wartość takiej "szczodrej" dotacji.
Nie powinno się zaczynać od tego typu projektów. Ja to znam z autopsji. Ludzie się napalają na projekt z kosmosu a po 2 dniach rezygnują bo nic z tego nie wychodzi.
Natomiast jeśli chodzi o użyczenie mocy obliczeniowej do testów albo puszczenie tego na wirtualce i raportowanie błędów - może odrobinę osób by się znalazło i może byłoby to użyteczne.Lepiej spytać,lepiej pomyśleć o wykorzystaniu KAŻDEJ możliwości. Wbrew pozorom samo bardziej masowe instalowanie tych poprawek na swoim kernelu i raportowanie błędów być może zaoszczędziłoby trochę roboty tym którzy są ekspertami od tego
@6a6b6c: grsecurity kernel STABLE wychodzi co tydzień-dwa, nawet dla 3.2 (a chwilę wcześniej dla 2.6 czy co tam miał debian wheezy) nie chodziło o nowości, tylko po prostu odkrywano błędy w kernelu, lub ulepszano zabezpieczenia grsecurity.
@xmesaj2: raczje nie, ale kto tam wie.. ( ͡° ͜ʖ ͡°)
Jeżeli znajdą się fundusze to będziemy mogli więcej uwagi poświęcić z powrotem temu projektowi.
OVH stosuje grsecurity, mam nadzieję że będą fundować Spendera (może już to robią zresztą)
A pensji minimalnej powinno nie być, na pewno nie od tego się tworzy bogactwo.