VPN-knoppie het sudo nodig: beperk die reël, valideer die beleid
’n Knoppie op die lessenaar is geen rede vir wortel sonder wagwoord nie. Kyk of die netwerkbestuurder dit self kan doen, beperk een opdrag, en valideer dan die hele sudo-beleid.
Die VPN-knoppie werk vir die administrateur en misluk vir almal anders, so iemand voeg ’n reël by sudoers. Daardie reël leef gewoonlik langer as die probleem wat dit moes oplos, en dit verleen dikwels meer as wat die knoppie nodig het. Voordat jy die beleid wysig, kyk of die ondersteunde eienaar van die verbinding reeds die werk kan doen. Die drie voorwaardes hieronder bepaal of sudo hoegenaamd betrokke is.
Voorwaarde 1: die ondersteunde eienaar kan dit sonder sudo doen
Op die meeste Linux-lessenaars besit die netwerkbestuurder reeds VPN-verbindings, en sy magtiging loop deur polkit eerder as sudo. ’n Gebruiker wat toegelaat word om ’n verbinding op te bring, kan dit vanaf die opdragreël doen sonder enige wortelreël. Kyk wat die bestuurder toelaat voordat jy aanneem die knoppie het voorreg nodig. As die antwoord ja is, dan los die sudoers-wysiging ’n probleem op wat nie bestaan nie.
nmcli connection show
nmcli connection up "Work VPN"
As die bestuurder weier, lees hoekom: ’n ontbrekende polkit-reël, ’n verbinding wat deur ’n ander gebruiker besit word, of ’n profiel wat gestoor is waar die gebruiker dit nie kan lees nie. Elkeen het ’n ondersteunde oplossing wat smaller is as ’n sudo-reël. ’n Voorregverhoging is die laaste uitweg, nie die eerste nie.
Voorwaarde 2: die reël noem een uitvoerbare lêer en sy argumente
As sudo werklik nodig is, moet die reël die presiese opdrag noem en, waar moontlik, die argumente wat dit mag gebruik. ’n Reël wat ’n gebruiker toelaat om ’n omhulselskrip te laat loop, is net so veilig soos daardie skrip se regte, want die gebruiker kan wysig wat wortel sal uitvoer. ’n Reël met ’n wildkaart ná die opdrag is dieselfde probleem in ’n korter vorm.
sudo -l -U alice
ls -l /usr/local/sbin/vpn-up
Kontroleer elke pad in die opdragketting: die program, die skrip wat dit oproep, die konfigurasielêer wat dit lees en enige gids daartussen. As enige van hulle deur die gebruiker skryfbaar is, is die beperkte reël in werklikheid onbeperkte wortel. Argumente maak ook saak, want ’n opdrag wat ’n konfigurasiepad aanvaar, kan na ’n lêer wys wat die gebruiker beheer. Skryf die reël vir die handeling, nie vir die knoppie nie.
Stop as die opdrag ’n lêer nodig het wat die gebruiker beheer om te werk. Dan is die ontwerp verkeerd, en geen sudoers-sintaks sal dit veilig maak nie.
Voorwaarde 3: die hele beleid ontleed, nie net jou reël nie
Valideer met die redigeerder wat die lêer sluit en sintaks kontroleer, en valideer die saamgestelde beleid eerder as ’n fragment. ’n Lêer wat op sy eie ontleed, kan steeds die insluitingsorde breek of ’n reël dupliseer op ’n manier wat gedrag verander.visudo-handleiding dokumenteer beide die sluitende redigeerder en die kontrole-modus wat hier gebruik word.
sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher
Die kontrole rapporteer die lêer en die reël wanneer dit misluk, en daardie verslag is die nuttige deel. Herstel die beoogde wysiging deur die redigeerder eerder as om ’n bekende fout met geweld te stoor, want ’n stukkende beleid kan elke administrateur gelyktydig uitsluit. Lêers onder die insluitingsgids het ook die eienaarskap en modus nodig wat die handleiding vereis, anders word hulle geïgnoreer of verwerp. Sintaks is net die eerste hek: nadat dit geslaag het, lees die reël weer en vra wat dit werklik toelaat.
Stop as die enigste manier om die wysiging te laat werk is om die sintakskontrole af te skakel. Dit is nie ’n beleid nie, dit is ’n onderbreking wat op ’n herbegin wag.
Herstel: hou ’n sessie wat steeds werk
Voordat jy stoor, maak seker ’n gemagtigde administratiewe sessie is reeds oop en dat ’n tweede pad na die masjien bestaan. ’n Sudoers-fout kan jou vermoë om dit reg te maak wegneem, en ’n knoppie op die lessenaar is daardie risiko nie werd nie. As sudo reeds stukkend is, gebruik die stelsel se gedokumenteerde herstelpad eerder as om een te improviseer.
sudo -n true
id
Alternatiewe soos pkexec hang van hul eie installasie en beleid af, so hulle is nie ’n gewaarborgde tweede wortelopdrag nie. Hou plaaslike magtiging ook apart van die verskaf van die VPN-geheim: ’n sudo-reël kan nie ’n afwesige geheime-agent ontsluit nie, en dit bevredig nie die poort se MFA nie. Na die regstelling, toets die normale rekening wat slegs die beoogde handeling uitvoer, en gebruik dan die bestuurder se gewone kontroles.
Die besluit eindig wanneer jy kan sê watter voorwaarde sudo geregverdig het, wat die reël noem, dat die hele beleid ontleed, en hoe jy sou herstel as dit nie die geval was nie. ’n Bevoorregte lanseerder wat jou administratiewe toegang kos, is ’n slegte ruil, en dit is gewoonlik ’n vermybare een.