VPN-kommandoen din kjører uprivilegert; tjenesten gjør det ikke

VPN-kommandoen kjører som brukeren din, ingen passord vises, og tunnelen kommer opp. Den sekvensen føles som en uprivilegert operasjon, og det er den vanligvis ikke. En egen tjeneste utfører nettverksendringene, og det interessante spørsmålet er hva den tjenesten vil gjøre for en kaller den ikke har verifisert. Å telle passordforespørsler sier deg ingenting om den grensen.

Grensesnittet, mekanismen og kontrollen

Grensesnittet godtar forespørsler: koble til, koble fra, velge en profil. Mekanismen eier nettverksoperasjonene: opprette grensesnitt, endre ruter, bruke filtre. Autorisasjonskontrollen avgjør om denne kalleren kan be om denne handlingen. Disse tre kan være spredt over en binærfil, en hjelper og en systemtjeneste, og brukeren ser bare den første.

Rollene kan bo i én binærfil, i to prosesser eller i en klient og en systemtjeneste, og kommandoen brukeren ser avslører sjelden hvilken. Et ikon i systemkurven og en systemdaemon kan se ut som én applikasjon mens de kjører med svært ulik myndighet. Privilegium ved installasjon og privilegium ved forespørsel er også forskjellige ting. En installatør som kjørte som root kan etterlate en tjeneste som lytter etter senere forespørsler, lenge etter at pakkebehandleren er ferdig. Det er den tjenesten, ikke kommandoen du skrev, som har myndigheten.

Delegering er det normale designet

Å delegere privilegert nettverksarbeid til en tjeneste er den fornuftige arkitekturen. Det holder vanlige applikasjoner uprivilegerte, og det sentraliserer operasjonene som trenger omhu. Designet lønner seg bare når tjenesten også kontrollerer hvem som spør og hvorfor. Uten den kontrollen er det bare en bredere dør.

NetworkManager er det konkrete Linux-eksempelet. Dens konfigurasjonsveiledning forklarer hvordan PolicyKit autoriserer forespørsler som ikke er fra root i standardoppsettet. Det viser delegert autorisasjon i et ekte produkt. Det beviser ikke at enhver kommersiell klient bruker NetworkManager, og det beskriver ikke noen bestemt leverandørs socket-sti eller policy.

Mønsteret er delegering med en policy bak. Eksempelet er én implementasjon av det mønsteret, ikke en universell.

Les grensen, ikke forespørselen

Finn tjenesten, eieren av konfigurasjonen og det lokale grensesnittet frontenden bruker. Spør så hvilke brukere som kan be om hvilke operasjoner. Å kunne heve og senke én lagret profil er ikke samme tillatelse som å laste inn konfigurasjon operatøren aldri har gjennomgått. Forskjellen er hele sikkerhetsspørsmålet.

Begynn med tjenestebehandleren og med klientens eget syn på sine tillatelser. Kommandoene nedenfor viser om daemonen kjører, hva kalleren kan be den om, og hva daemonen eksponerer under kjøretidskatalogen sin.

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

Spør også hva handlingen påvirker. Et menyelement som ser personlig ut kan endre ruter og DNS for hele maskinen, noe som betyr at det kan forstyrre andre brukeres økter. Virkningsradien hører hjemme i samme gjennomgang som tillatelsen, og den avgjør vanligvis om tjenesten trenger en snevrere rolle.

Rett tillatelser på den støttede måten

Å gjøre en beskyttet kontrollsocket skrivbar for alle, eller å legge en konto til en bred administrativ gruppe, fjerner en tillatelsesfeil og skaper en større. Feilen var det eneste som fortalte deg at den grensen fantes. Bruk den dokumenterte medlemskaps- eller autorisasjonsprosessen, inkludert øktfornyelsen den krever. Gruppemedlemskap gjelder ofte bare nye påloggingsøkter, og derfor kan en endring se ut til å ikke gjøre noe før neste pålogging.

Hvis produktet eksponerer en snevrere rolle for operasjonen, foretrekk den fremfor en generell tildeling. Skriv den valgte rollen og eieren av den ved siden av tjenestenavnet.

Hvordan en god oppdeling ser ut

Vanlige applikasjoner forblir uprivilegerte, tjenesten utfører bare oppsettet den er laget for, og hver kaller kontrolleres mot en policy noen eier. Det er et forsvarlig design. Det er også reviderbart, fordi policyen har et navn knyttet til seg. Alt større fortjener et skriftlig unntak i stedet for en stille tillatelsesendring.

Feilmodusen er en tjeneste som utfører enhver forespørsel fra enhver lokal bruker fordi grensesnittet er praktisk. Det ser identisk ut fra brukerens side, og det bærer en mye større myndighet. Test én avvist forespørsel, ikke bare den vellykkede. En avvisning som kommer fra policyen er beviset på at policyen finnes.