Je VPN-commando draait onbevoorrecht; de dienst niet
Geen wachtwoordvraag zegt niets over wie routes wijzigt. Zoek de dienst, de interface die hij aanbiedt en het beleid dat bepaalt welke aanroepers mogen vragen.
Het VPN-commando draait als jouw gebruiker, er verschijnt geen wachtwoord en de tunnel komt op. Die volgorde voelt als een onbevoorrechte bewerking, en dat is het meestal niet. Een aparte dienst voert de netwerkwijzigingen uit, en de interessante vraag is wat die dienst doet voor een aanroeper die hij niet heeft geverifieerd. Wachtwoordvragen tellen zegt je niets over die grens.
De interface, het mechanisme en de controle
De interface accepteert verzoeken: verbinden, verbreken, een profiel kiezen. Het mechanisme bezit de netwerkbewerkingen: interfaces aanmaken, routes wijzigen, filters toepassen. De autorisatiecontrole beslist of deze aanroeper om deze actie mag vragen. Die drie kunnen verdeeld zijn over een binair bestand, een helper en een systeemdienst, en de gebruiker ziet alleen de eerste.
De rollen kunnen in één binair bestand leven, in twee processen of in een client en een systeemdienst, en het commando dat de gebruiker ziet onthult zelden welke. Een pictogram in de systeembalk en een systeemdaemon kunnen op één toepassing lijken terwijl ze met heel verschillende bevoegdheid draaien. Bevoegdheid tijdens de installatie en bevoegdheid tijdens het verzoek zijn ook verschillende dingen. Een installatieprogramma dat als root liep kan een dienst achterlaten die op latere verzoeken luistert, lang nadat de pakketbeheerder klaar is. Die dienst, niet het commando dat je typte, heeft de bevoegdheid.
Delegeren is het normale ontwerp
Bevoorrecht netwerkwerk aan een dienst delegeren is de redelijke architectuur. Het houdt gewone toepassingen onbevoorrecht en centraliseert de bewerkingen die zorg vragen. Het ontwerp loont alleen als de dienst ook controleert wie er vraagt en waarvoor. Zonder die controle is het alleen een bredere deur.
NetworkManager is het concrete Linux-voorbeeld. De configuratiehandleiding legt uit hoe PolicyKit verzoeken die niet van root komen autoriseert in de standaardopstelling. Dat toont gedelegeerde autorisatie in een echt product. Het bewijst niet dat elke commerciële client NetworkManager gebruikt, en het beschrijft niet het socketpad of het beleid van een bepaalde leverancier.
Het patroon is delegeren met een beleid erachter. Het voorbeeld is één implementatie van dat patroon, niet een universele.
Lees de grens, niet het verzoek
Zoek de dienst, de eigenaar van zijn configuratie en de lokale interface die de frontend gebruikt. Vraag dan welke gebruikers welke bewerkingen mogen vragen. Eén opgeslagen profiel op en neer kunnen brengen is niet dezelfde toestemming als configuratie laden die de operator nooit heeft nagekeken. Het verschil is de hele beveiligingsvraag.
Begin bij de dienstbeheerder en bij de eigen kijk van de client op zijn toestemmingen. De commando's hieronder laten zien of de daemon draait, wat de aanroeper hem mag vragen en wat de daemon onder zijn runtijdmap aanbiedt.
systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager
Vraag ook waarop de bewerking invloed heeft. Een menu-item dat persoonlijk lijkt kan routes en DNS voor de hele machine wijzigen, wat betekent dat het de sessies van andere gebruikers kan verstoren. De impactstraal hoort bij dezelfde beoordeling als de toestemming, en bepaalt meestal of de dienst een nauwere rol nodig heeft.
Herstel toestemmingen op de ondersteunde manier
Een beschermde besturingssocket voor iedereen schrijfbaar maken, of een account aan een brede administratieve groep toevoegen, verwijdert een toestemmingsfout en maakt een grotere. De fout was het enige dat je vertelde dat die grens bestond. Gebruik het gedocumenteerde lidmaatschaps- of autorisatieproces, inclusief de sessievernieuwing die het vereist. Groepslidmaatschap geldt vaak alleen voor nieuwe aanmeldingssessies, waardoor een wijziging niets lijkt te doen tot de volgende aanmelding.
Als het product een nauwere rol voor de bewerking biedt, geef die dan de voorkeur boven een algemene toekenning. Schrijf de gekozen rol en de eigenaar ervan naast de dienstnaam.
Hoe een goede splitsing eruitziet
Gewone toepassingen blijven onbevoorrecht, de dienst voert alleen de opstelling uit waarvoor hij is ontworpen, en elke aanroeper wordt gecontroleerd tegen een beleid dat iemand bezit. Dat is een verdedigbaar ontwerp. Het is ook controleerbaar, omdat het beleid een naam heeft die eraan vastzit. Alles groter verdient een schriftelijke uitzondering in plaats van een stille toestemmingswijziging.
De faalmodus is een dienst die elk verzoek van elke lokale gebruiker uitvoert omdat de interface handig is. Van de gebruikerskant ziet het er identiek uit, en het draagt een veel grotere bevoegdheid. Test één geweigerd verzoek, niet alleen het geslaagde. Een weigering die uit het beleid komt is het bewijs dat het beleid bestaat.