Konsola jest uprawnieniem: dlaczego prosi o własne pozwolenie
Konsola wygląda jak ekran, ale jest powłoką. A możliwość zmiany ustawień i możliwość otwarcia powłoki to dwie różne moce; traktowanie jednej jak drugiej oznacza rozdawanie roota.
AtlasPVE ·
Ten wpis odpowiada na
- proxmox uprawnienie do konsoli
- proxmox sys.console co to jest
- dać użytkownikowi dostęp do powłoki w proxmoksie
- proxmox uprawnienia ról
- proxmox uprawnienie dostępu vnc
Konsola wygląda jak ekran. Otwierasz ją, pojawia się okno, przewija się w nim tekst. Ma się wrażenie, że tylko patrzysz.
Ale konsola jest powłoką. A powłoka na serwerze jest najwyższym uprawnieniem, jakie na tej maszynie istnieje.
Dwie osobne moce
Zmiana ustawień. Możesz robić to, na co pozwala interfejs. Granice są jasne, bo rysuje je interfejs.
Otwarcie powłoki. Możesz zrobić wszystko. Łącznie z rzeczami, których interfejs by odmówił, i takimi, o których interfejs nigdy nie słyszał.
Te dwie moce nie zawierają się w sobie. Posiadanie jednej nie wymaga drugiej, a co ważniejsze: nadanie jednej nie powinno oznaczać nadania drugiej.
Rozróżnienie jest prawdziwe i widać je we wbudowanych rolach
Proxmox wiąże konsolę z własnym, osobnym uprawnieniem, a nie z ogólnym uprawnieniem do zmian. Że jest to prawdziwe, widać po wbudowanych rolach: rola administratora systemu niesie uprawnienia audytu, konsoli i dzienników, a nie zawiera uprawnienia do zmian.
Jest więc uzasadnioną konfiguracją danie komuś prawa do otwierania konsoli bez prawa do zmiany ustawień. I odwrotnie także.
Częsta sytuacja, przez którą to ma znaczenie
Proxmox pozwala tworzyć własne role, a rola taka jak ta jest bardzo częsta: operator, który może zmieniać ustawienia sieci, ale nie powinien sięgać do powłoki serwera.
To rozsądne żądanie. Edytowanie konfiguracji sieci i uruchamianie dowolnego polecenia na serwerze to nie to samo.
Ale jeśli produkt rozumuje, że skoro może zmieniać, to może też otwierać konsolę, wręcza temu operatorowi powłokę roota, nawet tego nie zauważając. Dostaje on przez panel to, czego nie dostał w Proxmoksie.
Zasada ogólna, która z tego wynika
Model uprawnień musi kopiować własną definicję platformy, a nie ją parafrazować.
Brama mówiąca mniej więcej to samo działa poprawnie na zwykłych konfiguracjach i nikt niczego nie zauważa. Luka otwiera się w dniu, w którym powstaje nietypowa rola. A gdy ten dzień nadchodzi, nikt nie pamięta o przybliżeniu zapisanym lata wcześniej.
Ta sama poprzeczka dotyczy dostępu do plików
Jeszcze jeden szczegół, bo bywa pomijany: dostęp do systemu plików serwera jest równoważny powłoce nawet gdy jest tylko do odczytu.
Powód jest prosty: pliki haseł, klucze i sekrety klastra mieszkają w tym systemie plików. Ktoś z uprawnieniem tylko do odczytu, kto może czytać pliki, może już dowiedzieć się wszystkiego.
Dostępu do plików nie da się więc nadać uprawnieniem do patrzenia; żąda on tej samej poprzeczki co powłoka.
Co robi Atlas
W Atlasie konsola, zdalna powłoka i dostęp do plików są związane wyłącznie z uprawnieniem do konsoli. Samo uprawnienie do zmian tych powierzchni nie otwiera.
Nie zawsze tak było i wpis musi skończyć się uczciwie: te powierzchnie przyjmowały kiedyś także uprawnienie do zmian. Komentarz w kodzie mówił rzecz właściwą, mówił, że odpowiednikiem jest uprawnienie do konsoli, ale kod robił co innego.
Znaleziono to, mierząc wobec własnej definicji Proxmoksa, i poprawiono. Pomiar był jednoznaczny: Proxmox wiąże powłokę wyłącznie z uprawnieniem do konsoli i nie przyjmuje uprawnienia do zmian.
Prawdziwą wagę też trzeba podać taką, jaka jest: przy wbudowanych rolach nie dawało się tego wykorzystać, bo jedyna wbudowana rola zawierająca uprawnienie do zmian ma również uprawnienie do konsoli. Ryzyko leżało we własnych rolach, czyli w opisanym wyżej przykładzie operatora sieci.
Wynikająca z tego lekcja dotyczy samego produktu: to, że komentarz jest słuszny, nie znaczy, że kod jest słuszny. Te dwie rzeczy trzeba mierzyć osobno.
Źródła
Własna dokumentacja Proxmoksa. Po angielsku i to ona ma ostatnie słowo w tej sprawie.