Grsecurity [R.I.P] - koniec. Co dalej ?

[bryn1u 17]

Bry dzien,

 

Czy juz wiecie czy nie wiecie a jak nie wiecie to wam powiem.Niie ma juz dostepnych zadnych patch'y Grsecurity nawet testowych. Wszystko poszlo w komercje i jest platne. Zastanawiam sie co z projektami typu gentoo-hardened, gdzie juz zaczynaja sie pytania na liscie mailingowej. To samo arch-hardened i kernel w debian repository z grecurity mozna tez wspomniec o projekcie Mempo.

 

Ciekawi mnie co wy zrobicie teraz majac np spatchowane servery z grsecurity ? Szukacie jakiejs innej alternatywy typu SElinux lub Apparmor, ale jak wiadomo nie jest to samo.

 

Czy ktos slyszal o projeckie KSPP i wie jaki jest jego status czy jest szansa na jego szybszy rozwoj poprzez zamkniecie "open source" - grsec ?

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

 

Osobiscie uzywam FreeBSDHardened a dokladnie projekt, ktory sie nazywa HardenedBSD.

 

http://hardenedbsd.org/content/easy-feature-comparison

 

Jakby ktos potrzebowal jakiegos info na ten temat to sluze pomoca.

 

Pozdrawiam,

Edytowano Kwiecień 29, 2017 przez bryn1u (zobacz historię edycji)

[Lokator 137]

Czekam na wypowiedź ego w tym temacie ; )

[Pan Kot 1535]

 

Nigdy nie lubiłem gościa . Będę musiał sobie nową zabawkę znaleźć. Szkoda, że tak to się skończyło ale cóż, jego wybór.

Nieco rozwijając to osobiście nie widzę tutaj zbytniej tragedii bo było to do przewidzenia, a sam przestałem korzystać z grseca już jakiś czas temu, najzwyczajniej w świecie dlatego, że nie hostuję kontenerów typu docker czy innych VPSów na OpenVZ, żeby aż tak obawiać się ataku na kernel. Za to jak najbardziej SELinux/AppArmor jest tutaj bardzo fajny do kontroli typowych usług na serwerach, więc na pewno warto się zainteresować jeśli ktoś jeszcze tego nie zrobił.

Ale nie podoba mi się, że nie dał nawet tygodnia na ściągnięcie starych patchy, czy chociaż stworzenie repo na githubie z ostatnią free wersją - i tak się pojawi (a pewnie już jest), po prostu nie od niego. Grsec to naprawdę kawał dobrego kodu, którym torvalds mógłby się w końcu zainteresować i wrzucić wiele z tych patchy do mainstreama, żeby nie tylko to było dostępne out-of-the-box, ale i żeby community to wspierało.

Zapewne zareagowałbym zupełnie inaczej i i wylałbym wiadro pomyj gdybym przypadkowo nie przestał patchować grseciem mojego kernela kilka miesięcy temu - net core mi nie działał, a nie chciało mi się jeszcze sprawdzać dlaczego, teraz widzę że dobrze bo bym tylko czas stracił .

Jak Spender ładnie wspomniał w artykule - nie, alternatywy nie ma, są tylko ogromnie okrojone systemy typu SELinux/AppArmor, przynajmniej na tą chwilę. Czy warto się nimi zainteresować - na pewno, ale każda osoba, która rzeczywiście korzystała z grseca dobrze wie, że to zupełnie inna kategoria.

Edytowano Kwiecień 29, 2017 przez Archi (zobacz historię edycji)

[Lokator 137]

Czy ktoś wie jak z grsec w kernelach ovh?

[Pan Kot 1535]

Czy ktoś wie jak z grsec w kernelach ovh?

 

W zależności od tego jaką mają umowę ze spenderem - domyślna nie pozwala na umieszczanie łatek w postaci kodu źródłowego, a zatem zapomnij o kompilacji samemu.

 

Za to nadal mogą instalować swoje własne kernele z grseciem na swoich maszynach, po prostu bez kodu grseca na ftp://ftp.ovh.net/made-in-ovh/bzImage

 

I osobiście sądzę, że właśnie to się stanie - jeśli nie zrezygnują z grseca całkowicie (a nie mają po co, już i tak zapłacili), to po prostu nie będą umieszczali jego kodu źródłowego w swoich repo. 99% osób to w ogóle nie dotyczy, bo i tak nic nie zmieniają, a ten 1% który potrzebuje własnego kernela nowszego niż ten z OVH, będzie musiało coś wymyślić.

 

Osobiście uważam, że najlepszym rozwiązaniem w takim przypadku (OVH + grsec) będzie po prostu włączenie netboota na ostatniego grseca i rebootowanie systemu co jakiś czas na nową wersję. Jak ktoś nie potrzebuje własnych łatek to nie będzie zawiedziony.

Edytowano Kwiecień 29, 2017 przez Archi (zobacz historię edycji)

[bryn1u 17]

 

W zależności od tego jaką mają umowę ze spenderem - domyślna nie pozwala na umieszczanie łatek w postaci kodu źródłowego, a zatem zapomnij o kompilacji samemu.

 

Za to nadal mogą instalować swoje własne kernele z grseciem na swoich maszynach, po prostu bez kodu grseca na ftp://ftp.ovh.net/made-in-ovh/bzImage

 

I osobiście sądzę, że właśnie to się stanie - jeśli nie zrezygnują z grseca całkowicie (a nie mają po co, już i tak zapłacili), to po prostu nie będą umieszczali jego kodu źródłowego w swoich repo. 99% osób to w ogóle nie dotyczy, bo i tak nic nie zmieniają, a ten 1% który potrzebuje własnego kernela nowszego niż ten z OVH, będzie musiało coś wymyślić.

 

Osobiście uważam, że najlepszym rozwiązaniem w takim przypadku (OVH + grsec) będzie po prostu włączenie netboota na ostatniego grseca i rebootowanie systemu co jakiś czas na nową wersję. Jak ktoś nie potrzebuje własnych łatek to nie będzie zawiedziony.

 

1) Kernele OVH o ile dobrze pamietam nie maja polowy "features" grsec skompilowanych, wiec to tez roznie moze byc.

2) Podalem alternatywe grsec jako hardenedbsd.org (tak wiem to nawet nie jest linux), ale obsluguje juz nawet dockery

 

3) To moze odrazu podam pare linkow:

 

https://www.grsecurity.net/~paxguy1/ - od 2.2.26 - 4.9.24

 

https://dev.gentoo.org/~blueness/hardened-sources/hardened-patches/ - latko z gentoo-hardened tez do 4.9.24

 

https://github.com/slashbeast/grsecurity-scrape/tree/master/test - wszystkie latki grsec

 

SELinux - bardzo dobrze izlouje kontenery typu systemd-nspawn, dockery oraz kvm. W dodatku ma takie 3 opcje ktorymi warto sie zainteresowac.

selinuxuser_execheap --> off

selinuxuser_execmod --> off

selinuxuser_execstack --> off

 

No i jak juz wiadomo nie jest to grsec

 

@Archi

A o tym projekcie cos slyszales moze ?

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project

 

Edytowano Kwiecień 29, 2017 przez bryn1u (zobacz historię edycji)