Konsollen er et privilegium: hvorfor den krever sin egen tillatelse

En konsoll ser ut som en skjerm, men er et skall. Og "kan endre innstillinger" og "kan åpne et skall" er to ulike makter; å ta den ene for den andre er å dele ut root.

AtlasPVE ·

Denne artikkelen svarer på

  • proxmox konsolltillatelse
  • hva er sys.console i proxmox
  • proxmox gi bruker skalltilgang
  • proxmox rollerettigheter
  • proxmox vnc tilgangsrett

En konsoll ser ut som en skjerm. Du åpner den, et vindu dukker opp, tekst ruller i det. Det føles som "jeg bare ser på".

Men en konsoll er et skall. Og tjenerens skall er den høyeste retten som finnes på den maskinen.

To ulike makter

Å endre innstillinger. Du kan gjøre det grensesnittet tillater. Grensene er klare, for det er grensesnittet som trekker dem.

Å åpne et skall. Du kan gjøre hva som helst. Også det grensesnittet ville nekte, og det grensesnittet aldri har hørt om.

Disse to maktene rommer ikke hverandre. Å ha den ene krever ikke den andre, og viktigere: å innvilge den ene bør ikke bety å innvilge den andre.

Skillet er ekte og synes i de innebygde rollene

Proxmox binder konsollen til sin egen tillatelse, ikke til det allmenne "kan endre". At det er ekte, ser du i de innebygde rollene: rollen som systemforvalter bærer gransknings-, konsoll- og loggrettene og inneholder ingen endringsrett.

Det er altså et gyldig oppsett å gi noen retten til å åpne en konsoll uten retten til å endre innstillinger. Og motsatt også.

Den vanlige situasjonen som gjør dette viktig

Proxmox tillater egne roller, og en slik rolle er svært vanlig: en operatør som kan endre nettverksinnstillinger, men ikke skal nå tjenerens skall.

Det er et rimelig ønske. Å endre nettverksoppsettet og å kjøre hvilken som helst kommando på tjeneren er ikke det samme.

Men resonnerer et produkt "kan vedkommende endre, kan vedkommende også åpne konsollen", gir det den operatøren et rotskall uten å merke det. Vedkommende får gjennom panelet det han ikke ville fått i Proxmox.

Det allmenne prinsippet som følger

En rettighetsmodell må kopiere plattformens egen definisjon, ikke omskrive den.

En port som sier "omtrent det samme", virker riktig i vanlige oppsett, og ingen merker noe. Hullet åpner seg den dagen en uvanlig rolle blir laget. Og når den dagen kommer, husker ingen en tilnærming skrevet år tidligere.

Samme listen gjelder filtilgang

Enda en detalj, for den overses ofte: tilgang til tjenerens filsystem tilsvarer et skall selv når den bare er lesende.

Grunnen er enkel: passordfiler, nøkler og klyngehemmeligheter ligger i det filsystemet. Den som med en bare lesende rett kan lese filer, kan allerede få vite alt.

Filtilgang kan altså ikke innvilges med en rett til å "se"; den krever samme liste som et skall.

Hva Atlas gjør

I Atlas er konsollen, fjernskallet og filtilgangen bundet til bare konsolltillatelsen. Endringsretten alene åpner ikke disse flatene.

Slik har det ikke alltid vært, og artikkelen må slutte ærlig: før godtok disse flatene også endringsretten. Kommentaren i koden sa det riktige, den sa "motstykket er konsolltillatelsen", men koden gjorde noe annet.

Det ble funnet ved å måle mot Proxmox sin egen definisjon, og det ble rettet. Måleresultatet var tydelig: Proxmox binder skallet bare til konsolltillatelsen og godtar ikke endringsretten.

Den virkelige tyngden bør også sies som den er: det var ikke utnyttbart med innebygde roller, for den eneste innebygde rollen som inneholder endringsretten, har også konsolltillatelsen. Risikoen lå i egne roller, altså i eksempelet med nettverksoperatøren over.

Lærdommen som følger, gjelder også produktet selv: at en kommentar har rett, betyr ikke at koden har rett. De to må måles hver for seg.

Kilder

Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.

Relaterte artikler

Hvordan ser dette ut inne i Atlas?

Gå til produktsiden