stabilna wersja PLD :)

[Tomasz Pala]

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 <gotar at pld-linux.org>