Puncte:7

Oferiți utilizatorilor non-root permisiunea de a folosi un port

drapel jp

Găzduiesc un server de laborator unde sunt root (și un utilizator obișnuit).

Numele de domeniu este example.org și îi dau fiecărui membru un subdomeniu, de exemplu bob.example.org pentru Bob și anna.example.org pentru utilizatorul Anna. Cred că ai primit înțelegerea. :) Subdomeniile sunt inversate prin proxy folosind nginx către un anumit port.

Intrebarea mea este, există vreo modalitate prin care pot acorda permisiunea utilizatorilor care nu sunt root pentru a porni containerele docker pe gama lor specifică de porturi. De exemplu, Anna are intervalul 1300-1350, unde portul 1300 este legat la anna.example.org, iar celelalte sunt în rezervă.

Sistemul rulează Debian 11 Bullseye și cea mai recentă versiune Docker.

Cyclic3 avatar
drapel br
Aș fi *foarte* atent în a le oferi utilizatorilor non-root acces la docker.Este la fel de simplu ca `docker run -v /:/pwn -it cyclic3/pwn` pentru a obține acces complet r/w la întregul sistem de fișiere, iar adăugarea `--privileged` este aproape identică din punct de vedere funcțional față de a fi root pe acea mașină . Am văzut acest lucru greșit de atâtea ori, inclusiv într-un CTF condus de o mare companie cibernetică unde a fost intenționat pentru o singură provocare, dar a ajuns să expună toate mașinile folosite pentru acea categorie. Se poate face în siguranță, dar cred că este foarte important să subliniem cât de departe poate merge acest lucru.
Oscar Andersson avatar
drapel jp
Comentariu minunat despre anecdota CTF. Uneori concurez în acelea chiar și eu. Sună ca o competiție distractivă! :) Oricum, am decis să izolez complet utilizatorul folosind containere diferite, fără nici un acces la gazdă, cu excepția unor porturi deschise. Mulțumesc pentru timpul acordat.
Puncte:9
drapel td
bob

AFAIK Linux are doar conceptul de porturi privilegiate versus porturi neprivilegiate.

Parametrul de reglare a nucleului Linux net.ipv4.ip_unprivileged_port_start definește porturile care sunt privilegiate. Toate porturile între 0 și net.ipv4.ip_unprivileged_port_start sunt privilegiati.

Porturile privilegiate pot fi utilizate numai de procese fie pornite de utilizatorul root, fie cu privilegii root sau de procese cărora li se atribuie capacitatea CAP_NET_BIND_SERVICE cu de exemplu sudo setcap cap_net_bind_service=ep /path/bin/application

Toate celelalte porturi nu sunt privilegiate și pot fi folosite de orice utilizator, atâta timp cât porturile nu sunt deja utilizate.

Nu cunosc vreo metodă alternativă care să permită anumitor utilizatori să utilizeze anumite porturi.

Oscar Andersson avatar
drapel jp
Mulțumesc @bob! Mă gândesc să ofer fiecărui utilizator un container docker cu Debian 11 în care să poată roaming liber, apoi leg porturile 80 și 22 la un subdomeniu al domeniului meu principal. Ce crezi despre? Poate adaugă un strat de securitate.
Puncte:6
drapel in

În primul rând, numai utilizatorilor de încredere ar trebui să li se permită să vă controleze demonul Docker

Daemonul docker rulează implicit ca root pe o instalare Debian Bullseye. Adăugarea unui utilizator la docher grupul îi oferă utilizatorului acces rădăcină psuedo datorită controlului asupra demonului docker care are această cantitate de acces. Fiecare utilizator din grupul docker va avea control complet asupra gazdei și a altor containere și poate rula un container care --publicaeste orice port.

Există câteva opțiuni pentru a oferi securitate utilizatorilor accesul la docker.

  1. Docker fără rădăcini
  2. sudo
  3. API

1. Docker fără rădăcini

A configurarea docker fără rădăcină ar permite fiecărui utilizator să ruleze un docker deamon. Pentru porturile mai mici de 1024, ar trebui să respecte informații despre porturile neprivilegiate bob furnizat deoarece fiecare utilizator își va „deține” propriul deamon. Docker oferă, de asemenea îndrumări aferente. Asta nu o împiedică pe Anna să ia portul lui Bobs.

2. sudo

Cea mai simplă metodă de a permite utilizatorilor să ruleze comenzi docker este de a oferi un script controlat de rădăcină prin sudo, care este fie static, fie controlează intrarea utilizatorului pentru argumente opționale:

#!/bin/bash
docker run --detach --publish 1300:1300 anna/app-image
anna ALL=(rădăcină) NOPASSWD: /usr/local/bin/start-anna-image

Dacă doriți ca utilizatorii să își poată adăuga propriile opțiuni, trebuie să fiți foarte atenți la controlul intrării lor, deoarece este foarte ușor să

3. Plugin de autorizare sau API pentru Docker

Deoarece Docker nu oferă niciun strat de autorizare pe demon, trebuie să adăugați ceva pentru a controla accesul utilizatorilor.

Docker oferă un sistem integrat plugin de autorizare cadru pentru a permite acest lucru. Câteva exemple sunt opa-docker-authz și casbin-authz-plugin

Puteți oferi utilizatorilor acces la o formă de API proxy care oferă autentificarea și autorizarea asupra a ceea ce este transmis API-ului REST Docker. Există biblioteci docker pentru majoritatea limbajelor de programare.Kubernetes+RBAC este un exemplu de API care se află în fața demonului Docker și controlează accesul (doar unul foarte mare/complex care face mult mai mult).

Oscar Andersson avatar
drapel jp
Mulțumesc @matt, într-adevăr! Ai adus în discuție câteva puncte bune, acum am încercat alternativele 1 și 2. Simt că dockerul fără root este puțin prea complicat pentru mine și seturile de reguli sudo necesită prea mult timp pentru mine. Ce părere aveți despre oferirea fiecărui utilizator propriul container în care pur și simplu SSH. Domeniul de aplicare al utilizatorilor nu acoperă nici măcar gazda. Care sunt beneficiile de securitate ale acestui lucru, după părerea dvs.? Mulțumiri.
Puncte:5
drapel cn

Atâta timp cât porturile nu sunt privilegiate, utilizatorii non-root se pot lega la orice port (peste 1024). Pot începe containerele cu:

docker run --expose 1300-1350 <nume-imagine>

Este primul venit, primul servit. Dacă două programe încearcă să se lege la același port, doar primul care se leagă va reuși.

Pentru porturile privilegiate (mai puțin de 1024), aveți nevoie de capacitatea root sau CAP_NET_BIND_SERVICE. Vedea capacitățile omului pentru detalii.

Oscar Andersson avatar
drapel jp
Multumesc Micea! Pot să adaug un utilizator non-root la grupul de utilizatori docker și să nu-i las să interfereze cu porturile privilegiate și cu alte containere? Așa că Anna nu poate vedea, edita sau elimina containerele lui Bob.
drapel cn
Containerele începute de un utilizator vor fi gestionate numai de acel utilizator. Puteți limita intervalele de porturi pe care containerele (sau orice aplicație) se pot lega prin SELinux sau AppArmor: https://serverfault.com/a/388334/30946
Matt avatar
drapel in
Dacă demonul docker rulează ca `rădăcină`, atunci nu contează ce utilizator execută comenzile `docker`. Utilizatorii au în esență acces root prin intermediul demonului care face treaba.
Matt avatar
drapel in
@OscarAndersson Nu, orice utilizator din grupul „docker”, în timp ce demonul docker rulează ca root, are acces root la mașină și poate controla alte containere
Nonny Moose avatar
drapel gb
De asemenea, rețineți că puteți redirecționa portul docker către un port privilegiat.
Oscar Andersson avatar
drapel jp
Mulțumesc @NonnyMoose, asta e ceva ce fac. :)
Oscar Andersson avatar
drapel jp
Multumesc @MirceaVutcovici care suna interesant, o sa ma uit. :)
Oscar Andersson avatar
drapel jp
Da, @Matt, acesta este un punct foarte bun.Nu sunt prea îngrijorat de faptul că utilizatorii mei sparg în mod deliberat sistemul, este mai mult că unii dintre ei nu au experiență în sistemele Linux și pot deschide găuri de securitate pentru hackeri. Voi lua în considerare comentariile tale.
Puncte:3
drapel in

Subdomeniile sunt inversate prin proxy folosind nginx către un anumit port.

Puteți proxy subdomeniile la socket-urile Unix.

    proxy_pass http://unix:/var/run/anna.sock:/;

Repetați după cum este necesar pentru fiecare subdomeniu și setați permisiunile pe socket-urile Unix, astfel încât numai utilizatorii doriti să poată asculta acolo.

De asemenea, rețineți că un utilizator care poate rula containere Docker se poate monta /etc/passwd în ele și să câștige rădăcină, astfel încât acestea trebuie protejate separat.

Matt avatar
drapel in
Idee bună, dar similar cu cel de-al doilea punct, docker ar putea monta orice priză, dacă nu adăugați o altă formă de control asupra a ceea ce un utilizator poate rula prin docker.
Oscar Andersson avatar
drapel jp
Koterpillar și @matt, pot lega/public un socket Unix prin docker sau ar trebui să folosesc porturi pentru asta? Citiți ceva despre faptul că nu este încă pe deplin acceptat de docker.
Oscar Andersson avatar
drapel jp
Mulțumim Koterpillar pentru că ați menționat implicațiile de securitate ale acordării de acces la docker utilizatorilor.
drapel in
Deoarece un socket UNIX este un fișier, încercați să îl montați pe container.
Puncte:1
drapel pk

Am vrut doar să adaug o altă perspectivă... cu siguranță mai multă muncă! Dar interesant...

Luați în considerare rularea unui orchestrator de containere, precum Kubernetes. Verifică KIND (Kubernetes-in-Docker) pentru o modalitate interesantă de a rula un cluster Kubernetes pe un singur nod cu doar Docker.

Ai putea atunci, de exemplu, să faci ceva de genul

Dacă structurați corect rolurile, utilizatorilor li se poate permite să lanseze orice containere doresc în spațiul lor de nume, dar nu li se va permite să modifice serviciu care defineşte porturile expuse.

Acest lucru este simplificat de dragul spațiului, dar primitivele pe care le oferă ceva de genul k8s sunt excelente pentru sistemele multi-chiriași ca acesta.

Oscar Andersson avatar
drapel jp
Mulțumesc Budris, postarea ta este cu adevărat inspirațională și puțin experimentală dacă pot spune așa. Cred totuși că este puțin prea complicat pentru mine. Mulțumiri.
Mr.Budris avatar
drapel pk
da, ceva de genul kubernetes este probabil exagerat pentru mediul tău, dar ține cont de sistemele de acest fel dacă laboratorul tău crește -- ar putea economisi mult timp (și ar putea fi o experiență de învățare interesantă) pentru viitor. Noroc!
Oscar Andersson avatar
drapel jp
Mulțumesc, cu siguranță sunt pregătit pentru experiența de învățare. :) (Btw mi-am rezolvat problema cu docker fără root, systemd persistent la nivel de utilizator și utilizatori obișnuiți non-root pe gazdă)

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.