On Mon, Jan 02, 2017 at 17:14:41 +0100, Paweł Gołaszewski wrote: > Lubisz się czepiać, prawda? ;)
Tylko się bronię! :) Chodzi mi o to, że przypadek, który masz na myśli - podałem od razu jako wyjątek. Przyznam, że zaczepnie, a nie wiedziałem nawet, że systemd się już dorobił grzecznego pomijania pewnych niedostępnych funkcji. Nie idzie co prawda tak daleko, jak niegdysiejszy tryb zdegradowany, ale to nawet dobrze. >> A konkretnie to jakie? Poważnie pytam - rzeczywisty przykład ułatwienia >> ucieczki z nieuprzywilejowanego kontenera. > > Nie mam czasu (ani ochoty) na advocacy. Szczególnie, że Ty jesteś w stanie > każdego zagadać na śmierć... nie ważne czy masz rację czy nie (no-offence, po > prostu "kilka" lat obserwuję i sam uczestniczyłem w dyskusjach z Tobą ;) > Możesz to potraktować jako komplement ;) ). Dzięki:) ale tak żebym się doedukował - czy chodzi o coś innego niż (na dole) https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/ ? > Pisałem jakiś czas temu, była krótka dyskusja na ten temat. Jesteś > zainteresowany to poszukaj. Sygnalizuję tylko problem, na który sam się > natknąłem. Z racji tego, że obecnie nie można zrobić separacji (nazwijmy to tak dla uproszczenia) zarówno wewnątrz kontenera jak i na zewnątrz, trzeba wybrać: 1. chcę separować niezaufany kontener od hosta (odpalam niezaufany kontener), 2. chcę mieć bezpieczny kontener z usługami, host na zewnątrz to tylko pojemnik, żeby się łatwiej administrowało. To jest popularny dylemat - np. dla normalnego użytkownika praca z konta roota nie jest niebezpieczna, bo to nie zawartość samego systemu jest ważna (analogia hosta), tylko jego katalogu domowego (kontenera). Niebezpieczeństwo czai się w pozornym bezpieczeństwie linuksa jako takiego, a tymczasem stracić własne dane jest równie łatwo (wyjątkiem jest Qubes OS). Zatem jeżeli wewnątrz kontenera masz aplikację wystawioną ryjkiem na świat, bazę danych i wszystko, co ważne - chcąc chronić kontener, lepiej mieć w środku systemd, a kontener uruchamiać z CAP_SYS_ADMIN. Jeżeli natomiast chcę izolować kontener od sąsiadów i hosta ogólnie... nadal uruchamiasz systemd, tyle że nieuprzywilejowany. Sytuacja będzie NIE GORSZA niż z rc-scripts, po prostu wewnątrz nie będzie żadnych (...?) funkcji ochrony. rc-scripts w ogóle ich nie mają. Obecnej sytuacji nie jest nikt winien: - systemd realizuje swoje funkcje ochronne, - docker realizuje swoje funkcje ochronne (gdy ktoś ma archaicznego inita albo po prostu obawia się wyeksploitowania zawartości), - kernel ma tylko takie user namespaces, że działają na jedym poziomie... To po co o tym rozmawiać? Bo mając systemd w kontenerze, możesz w każdej chwili przestawić na inny sposób uruchamiania. A gdy kiedyś te funkcje zostaną poprawione, to automatycznie zyskujesz. Win-win. A jeżeli chodzi o problemy, które napotkałeś - czy o to chodzi? https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2015-December/157189.html - jak na systemd to mówimy o zamierzchłej przeszłości, w PLD też nie byliśmy jakoś specjalnie na bieżąco. Zatem skoro da się już _w ogóle_ uruchomić systemd nieuprzywilejowany, to nie widzę żadnej przewagi rc-scripts w kontenerze. Trzeba po prostu być na bieżąco, ale OP pytał o nowy system i o takim ja się wypowiadałem. > Dobrze, źle - sprawa dyskusyjna. Szczególnie jak konserwujesz istniejące > systemy. Po prostu są i trzeba z tym żyć. Oj, że czasem trzeba sobie radzić z zaszłościami, to jasne. Ale właśnie po to, żeby sobie nie robić nowych zaszłości na przyszłość;) trzeba od razu decydować się na bardziej perspektywiczne rozwiązanie. A dzisiaj na horyzoncie poza systemd nie ma nic. Zatem na zakończenie, raz jeszcze: MOŻNA mieć DOBRY powód, żeby systemd nie używać, ale jeżeli się go nie zna, to defaultowo trzeba brać systemd. -- Tomasz Pala <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
