Ditt VPN-kommando körs oprivilegierat; tjänsten gör det inte

VPN-kommandot körs som din användare, inget lösenord visas och tunneln kommer upp. Den sekvensen känns som en oprivilegierad operation, och det är den oftast inte. En separat tjänst utför nätverksändringarna, och den intressanta frågan är vad den tjänsten gör för en anropare som den inte har verifierat. Att räkna lösenordsfrågor säger dig ingenting om den gränsen.

Gränssnittet, mekanismen och kontrollen

Gränssnittet tar emot förfrågningar: anslut, koppla från, välj en profil. Mekanismen äger nätverksoperationerna: skapa gränssnitt, ändra rutter, tillämpa filter. Auktoriseringskontrollen avgör om den här anroparen får begära den här åtgärden. De tre kan vara utspridda över en binär, en hjälpare och en systemtjänst, och användaren ser bara den första.

Rollerna kan bo i en enda binär, i två processer eller i en klient och en systemtjänst, och kommandot användaren ser avslöjar sällan vilken. En ikon i aktivitetsfältet och en systemdaemon kan se ut som en enda applikation medan de körs med mycket olika befogenhet. Behörighet vid installation och behörighet vid förfrågan är också olika saker. Ett installationsprogram som kördes som root kan lämna en tjänst som lyssnar på senare förfrågningar, långt efter att pakethanteraren är klar. Det är den tjänsten, inte kommandot du skrev, som har befogenheten.

Delegering är den normala designen

Att delegera privilegierat nätarbete till en tjänst är den rimliga arkitekturen. Det håller vanliga applikationer oprivilegierade och centraliserar operationerna som kräver omsorg. Designen lönar sig bara när tjänsten också kontrollerar vem som frågar och varför. Utan den kontrollen är det bara en bredare dörr.

NetworkManager är det konkreta Linux-exemplet. Dess konfigurationsguide förklarar hur PolicyKit auktoriserar förfrågningar som inte kommer från root i standarduppsättningen. Det visar delegerad auktorisation i en riktig produkt. Det bevisar inte att varje kommersiell klient använder NetworkManager, och det beskriver inte någon viss leverantörs socketväg eller policy.

Mönstret är delegering med en policy bakom. Exemplet är en implementering av det mönstret, inte en universell.

Läs gränsen, inte förfrågan

Hitta tjänsten, ägaren av dess konfiguration och det lokala gränssnitt som frontenden använder. Fråga sedan vilka användare som får begära vilka operationer. Att kunna höja och sänka en sparad profil är inte samma tillstånd som att läsa in en konfiguration som operatören aldrig har granskat. Skillnaden är hela säkerhetsfrågan.

Börja med tjänstehanteraren och med klientens egen syn på sina tillstånd. Kommandona nedan visar om daemonen körs, vad anroparen får begära av den och vad daemonen exponerar under sin körtidskatalog.

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

Fråga också vad åtgärden påverkar. Ett menyval som verkar personligt kan ändra rutter och DNS för hela maskinen, vilket betyder att det kan störa andra användares sessioner. Påverkansradien hör hemma i samma genomgång som tillståndet, och den avgör oftast om tjänsten behöver en snävare roll.

Rätta behörigheter på det stödda sättet

Att göra en skyddad kontrollsocket skrivbar för alla, eller att lägga till ett konto i en bred administrativ grupp, tar bort ett behörighetsfel och skapar ett större. Felet var det enda som berättade för dig att gränsen fanns. Använd den dokumenterade medlemskaps- eller auktoriseringsprocessen, inklusive den sessionsuppdatering den kräver. Gruppmedlemskap gäller ofta bara nya inloggningssessioner, och därför kan en ändring se ut att inte göra något förrän nästa inloggning.

Om produkten exponerar en snävare roll för åtgärden, föredra den framför ett generellt beviljande. Skriv den valda rollen och dess ägare bredvid tjänstens namn.

Hur en bra uppdelning ser ut

Vanliga applikationer förblir oprivilegierade, tjänsten utför bara den uppsättning den är byggd för, och varje anropare kontrolleras mot en policy som någon äger. Det är en försvarbar design. Den är också granskningsbar, eftersom policyn har ett namn knutet till sig. Allt större förtjänar ett skriftligt undantag i stället för en tyst behörighetsändring.

Felläget är en tjänst som utför vilken förfrågan som helst från vilken lokal användare som helst därför att gränssnittet är bekvämt. Från användarens sida ser det identiskt ut, och det bär en mycket större befogenhet. Testa en avvisad förfrågan, inte bara den lyckade. Ett avslag som kommer från policyn är beviset för att policyn finns.