Forum Debian Users Gang

[quote=bryn1u]Jezeli ASLR jest dla niego obscurity to po prostu kwalifikuje sie do takiego samego podejscia jak Torvalds w kwestii beczpieczenstwa, a pozniej wcyhodza expolity na linuxa jak do tej pory.[/quote]
Nie chcę bronić [b]phk[/b], natomiast nie wstawiałbym autora jaili do butów w których chodzi [b]Linus Torvalds[/b].

W 2006 r. [b]Kristaps Dzonsons[/b] zaproponował w OpenBSD mechanizm sysjail czyli klona jaili opartego o bibliotekę systrace [b]Nielsa Provosa[/b]. W 2007 roku programista [b]Robert N. M. Watson[/b] opublikował artykuł pt.[b] [i] Exploiting Concurrency Vulnerabilities in System Call Wrappers[/i][/b] [w:] http://www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf w którym udowodnił, iż podłoże sysjaila jest dziurawe - projekt został szybko wygaszony przez OpenBSD jak i NetBSD.

Nadmienić też muszę, że Watson razem z Kampem brał udział w tworzeniu jaili, a od kwietnia 1999 r. nikt nie wykazał [b]w żadnym dokumencie[/b] dziur w celach, na tej samej zasadzie co Watson uczynił z sysjailami.

Kernel FreeBSD oferuje od dawna mechanizmy obrony / te ustawia się w pliku sysctl.conf / a które od wersji 11 w instalatorze są bardziej eksponowane jak:

    Hide processes running as other users = security.bsd.see_other_uids
    Hide processes running as other groups = security.bsd.see_other_gids
    Disable reading kernel message buffer for unprivileged users = security.bsd.unprivileged_read_msgbuf
    Disable process debugging facilities for unprivileged users = security.bsd.unprivileged_proc_debug
    Randomize the PID of newly created processes = kern.randompid
    Insert stack guard page ahead of the growable segments = security.bsd.stack_guard_page

Ostatnio edytowany przez mfm (2017-03-07 11:22:59)

[quote=bryn1u]Co do jaili to byl tez exploitm ktory pozwolil wyjsc z jaila . Co prawda dawno dawno temu, ale byl.[/quote]
Mowa o Security Advisory z grudnia 2008 r. o numerze FreeBSD-SA-08:13[b] i nie było to związanie z błędem w kodzie tworzącym jaile[/b],  a z jednym modułów netgrapha(4) - konkretnie z bugiem w stosie ng_bluetootha(4), tzn. jeżeli miałeś system  na którym były postawione cele i kernel miał załadowane moduły ng_socket(4) i ng_bluetooth(4) a pakiety sieciowe przepuszczałeś na linii cele <---> host przez netgrapha to mogło dojść do eskalacji przywilejów.

Niemniej taka konfiguracja cel nie była zalecana wtenczas [i nie jest obecnie], jak to Watson stwierdził:[b][i] In the default FreeBSD jail configuration, it is not possible to break out of jails with this vulnerability, but if the setting to allow additional protocol access from jails is enabled, then it is possible. Changing that setting is generally not considered advisable because it allows use of protocols not specifically adapted for use in Jail.[/i][/b]

Co nie oznacza, że należy zapomnieć o netgraphie. Jest to bardzo użyteczne środowisko,  ale tylko do zastosowań testowych, nauki budowania rozległych połączeń i sprawdzania różnych protokołów. Można dokładnie przyglądać się obciążeniu cel w praktyce np. jak radzą sobie z przetwarzaniem baz SQL i obsługą zapytań w sieci. Osobiście ze względów bezpieczeństwa nie radziłbym stosowania łączności netgraphem w środowisku produkcyjnym.

Przyszłością na tym polu będzie vnet(9), ale zapewne nie prędko się to stanie.

[quote=bryn1u]@mfm
Tak miedzy niebem a prawda to obrona w FreeBSD przeciwko exploitom w ogole nie istnieje. To co wkleiles ma sie nijak do obrony przeciwko exploitom.  Jezeli chcesz cos co naprawde dziala przeciwko expolityzacji to jest HardenedBSD, niestety FreeBSD lezy i kwiczy przy tych technologiach. Jezeli bedzie dziura w kernelu FreeBSD to nic nie zrobisz. Oczywiscie nic nie ujmujac FreeBSD.[/quote]
[b]bryn1u[/b] - irytuje mnie cały ten hype związany z "security", miesza się często pojęcia, bez wiedzy i dobrego wyjaśnienia, co z czym się łączy i na czym polega. To że coś funkcjonuje np. w OpenBSD, nie znaczy że będzie tak samo dobrze funkcjonować w FreeBSD.
Zasada funkcjonowania jądra nie jest znana każdemu, a lektura kodu źródłowego i zrozumienie jego zawiłości wymaga wiedzy i możliwości intelektualnych, tłumaczenie z tego poziomu bywa nudne dla większości, inaczej się ma z cudownymi rozwiązaniami do przeciwdziałania "exploitowalności", podaje się systemy A, B, Z, Y, które gdy są powłączane robią z sytemu fortecę.

Francuzi budowali od lat 20'tych potężną linię obronną, którą nazwali Maginota, tam gdzie się znajdowała atakujący poległby marnie, niemniej Niemcy postanowili obejść ją przez... neutralną Belgię - francuzom myśl o pogwałceniu neutralności cudzego państwa przez głowę by nie przeszła, zatem też nie umieścili na granicy z Belgią praktycznie żadnych umocnień.

Pierwsza zasada budowania bezpiecznych systemów jest taka, że nie mówisz potencjalnemu atakującemu, gdzie stawiasz i jakie stawiasz zasieki. Warto poczytać klasyka w postaci Clausewitza by to zrozumieć. Bo odgórna zasada obrony przed zagrożeniami bywa sprowadzona do taktyk obronnych, a nie jak powinno być do całej strategii.

Ostatnio edytowany przez mfm (2017-03-07 15:08:01)

[b]bryn1u[/b] - OpenBSD bardzo sobie cenię. Pod względem jakości jest to najlepszy projekt z rodziny BSD - przypomina mi w każdym miejscu Solarisa, firmy Sun Microsystems.
Od zawsze stawiają na minimalizm, prostotę, czytelność.

FreeBSD wykonuje robotę, którą mu nakazuję, natomiast mam wrażenie graniczące z pewnością, że z wersji na wersję robi się on coraz grubszy :)

Temat bezpieczeństwa zostawiam do oceny własnej.

Pozdrawiam

Ostatnio edytowany przez mfm (2017-03-07 19:50:21)