Din VPN-kommando kører uprivilegeret; tjenesten gør ikke

VPN-kommandoen kører som din bruger, der vises ingen adgangskode, og tunnelen kommer op. Den sekvens føles som en uprivilegeret handling, og det er den som regel ikke. En separat tjeneste udfører netværksændringerne, og det interessante spørgsmål er, hvad den tjeneste vil gøre for en kaldende part, den ikke har verificeret. At tælle adgangskodeforespørgsler fortæller dig intet om den grænse.

Grænsefladen, mekanismen og kontrollen

Grænsefladen accepterer anmodninger: forbind, afbryd, vælg en profil. Mekanismen ejer netværkshandlingerne: oprette grænseflader, ændre ruter, anvende filtre. Autorisationskontrollen afgør, om denne kaldende part må bede om denne handling. De tre kan være spredt over en binær fil, en hjælper og en systemtjeneste, og brugeren ser kun den første.

Rollerne kan bo i én binær fil, i to processer eller i en klient og en systemtjeneste, og den kommando, brugeren ser, afslører sjældent hvilken. Et ikon i proceslinjen og en systemdaemon kan se ud som én applikation, mens de kører med meget forskellig myndighed. Privilegium på installationstidspunktet og privilegium på anmodningstidspunktet er også forskellige ting. Et installationsprogram, der kørte som root, kan efterlade en tjeneste, der lytter efter senere anmodninger, længe efter at pakkehåndteringen er færdig. Det er den tjeneste, ikke den kommando du skrev, der har myndigheden.

Delegering er det normale design

At delegere privilegeret netværksarbejde til en tjeneste er den rimelige arkitektur. Det holder almindelige applikationer uprivilegerede, og det centraliserer de handlinger, der kræver omhu. Designet betaler sig kun, når tjenesten også kontrollerer, hvem der spørger, og om hvad. Uden den kontrol er det bare en bredere dør.

NetworkManager er det konkrete Linux-eksempel. Dens konfigurationsvejledning forklarer, hvordan PolicyKit autoriserer anmodninger, der ikke er fra root, i standardopsætningen. Det viser delegeret autorisation i et rigtigt produkt. Det beviser ikke, at enhver kommerciel klient bruger NetworkManager, og det beskriver ikke nogen bestemt leverandørs socket-sti eller politik.

Mønsteret er delegering med en politik bag sig. Eksemplet er én implementering af det mønster, ikke en universel.

Læs grænsen, ikke anmodningen

Find tjenesten, ejeren af dens konfiguration og den lokale grænseflade, som frontenden bruger. Spørg så, hvilke brugere der må anmode om hvilke handlinger. At kunne hæve og sænke én gemt profil er ikke samme tilladelse som at indlæse konfiguration, som operatøren aldrig har gennemgået. Forskellen er hele sikkerhedsspørgsmålet.

Begynd med tjenestestyringen og med klientens eget syn på sine tilladelser. Kommandoerne nedenfor viser, om daemonen kører, hvad den kaldende part må bede den om, og hvad daemonen udstiller under sin runtime-mappe.

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

Spørg også, hvad handlingen påvirker. Et menupunkt, der ser personligt ud, kan ændre ruter og DNS for hele maskinen, hvilket betyder, at det kan forstyrre andre brugeres sessioner. Rækkevidden hører til i samme gennemgang som tilladelsen, og den afgør som regel, om tjenesten har brug for en snævrere rolle.

Ret tilladelser på den understøttede måde

At gøre en beskyttet kontrolsocket skrivbar for alle, eller at føje en konto til en bred administrativ gruppe, fjerner en tilladelsesfejl og skaber en større. Fejlen var det eneste, der fortalte dig, at grænsen fandtes. Brug den dokumenterede medlemskabs- eller autorisationsproces, inklusive den sessionsfornyelse, den kræver. Gruppemedlemskab gælder ofte kun for nye loginsessioner, og derfor kan en ændring se ud til ikke at gøre noget indtil næste login.

Hvis produktet udstiller en snævrere rolle til handlingen, foretræk den frem for en generel bevilling. Skriv den valgte rolle og dens ejer ved siden af tjenestens navn.

Sådan ser en god opdeling ud

Almindelige applikationer forbliver uprivilegerede, tjenesten udfører kun den opsætning, den er designet til, og enhver kaldende part kontrolleres mod en politik, som nogen ejer. Det er et forsvarligt design. Det er også reviderbart, fordi politikken har et navn knyttet til sig. Alt større fortjener en skriftlig undtagelse i stedet for en stille tilladelsesændring.

Fejltilstanden er en tjeneste, der udfører enhver anmodning fra enhver lokal bruger, fordi grænsefladen er bekvem. Det ser identisk ud fra brugerens side, og det bærer en meget større myndighed. Test én afvist anmodning, ikke kun den vellykkede. En afvisning, der kommer fra politikken, er beviset på, at politikken findes.