Stapel systemd-hardening niet op de user-overgang van OpenVPN

Twee aan elkaar geplakte recepten met minimale rechten leveren geen strengere uitrol op. Het ene model laat de daemon met rechten starten en na de initialisatie terugvallen naar een account zonder rechten; het andere laat de servicemanager hem vanaf de eerste instructie onder een beperkte identiteit starten. Elk werkt op zichzelf, en de combinatie levert vaak een dienst op die geen van beide taken netjes kan uitvoeren. De rest loopt de beslissing op volgorde door.

Twee modellen, één eigenaar van de wissel

Het eerste model hoort bij de daemon. De communityversie van OpenVPN heeft de opties user en group, die de identiteit wisselen nadat de tunnel en de sleutels zijn ingesteld, en persist-key plus persist-tun houden die bronnen daarna bruikbaar.

Het tweede model hoort bij de servicemanager. Een systemd-instelling User= of Group= bepaalt de identiteit waaronder het proces start, en capability-richtlijnen bepalen wat het mag vasthouden. De keuze tussen de modellen is een verpakkingsvraag voordat het een beveiligingsvraag is, en de pakketbeheerder heeft die al beantwoord. Uw taak is dat antwoord te vinden in plaats van een derde optie te verzinnen.

Beide zijn legitiem. De fout is ze als lagen van één ontwerp te behandelen, omdat het tweede model de identiteitswissel van het eerste tot een handeling kan maken die het proces niet meer mag uitvoeren.

Bepaal waar de identiteit wisselt

Als de unit al als eigen account start, vraagt een daemoninstructie om een ander account te worden om een setuid-overgang die een geharde dienst nooit had moeten maken. De fout verschijnt als een rechtenfout bij het starten in plaats van als een duidelijke beleidsmelding. Het leest als een ontbrekende capability, wat mensen naar een bredere begrenzingsset stuurt in plaats van naar de identiteitsvraag.

Lees wat het geïnstalleerde pakket werkelijk meelevert voordat u iets bewerkt, inclusief de drop-in-map. Sommige units laten de eigen overgang van de daemon bewust weg omdat de manager die al afhandelt, en sommige vertrouwen voor de wissel na de initialisatie op die opties. Een van beide verwijderen zonder te weten welk model u hebt geërfd, is hoe een werkende dienst ophoudt met starten.

Schrijf het gekozen model op één regel: manager-eigen of daemon-eigen. Elke latere richtlijn moet met die zin overeenkomen, en een gemengde unit moet als fout worden behandeld en niet als compromis.

Capabilities zijn grenzen, geen giften

Een capability-begrenzingsset zegt wat een proces hoogstens mag vasthouden. Het is een plafond, en een capability daar vermelden geeft op zichzelf niets, waardoor een unit met een ruime begrenzingsset toch geen tunnel kan aanmaken.

Wat een capability werkelijk in de ambient-set van een dienst plaatst, is AmbientCapabilities=. De systemd-uitvoeringsreferentie documenteert de twee richtlijnen apart, en dat onderscheid verklaart het grootste deel van het verwarrende capability-advies online.

Voeg een capability pas toe nadat de falende handeling hem heeft geïdentificeerd. Een bredere begrenzingsset verbergt de echte oorzaak en laat de dienst meer rechten houden dan het ontwerp bedoelde. Het maakt de unit ook moeilijker te beoordelen, omdat het plafond de taak niet meer beschrijft. Verwijder de extra capability zodra de echte fout is verholpen.

Breng de bevoegdheid over de levenscyclus in kaart

Som op wat het proces in elke fase moet doen: start, stabiele toestand, herauthenticatie en afbouw. Het aanmaken van interfaces, routewijzigingen, het lezen van een beschermde sleutel en het aanroepen van een helper gebeuren niet allemaal op hetzelfde moment of onder dezelfde eisen. Sorteer de lijst op fase voordat u die op capability sorteert.

Persistentie-opties bewaren bronnen over heronderhandeling heen, en ze verlenen geen rechten die nooit zijn gehouden. Een sleutel die het proces bij het starten niet kan lezen, blijft later ook onleesbaar, wat de persistentievlaggen ook zeggen. De vlaggen bewaren wat al werkte.

Gebruik een eigen account in plaats van een gedeeld account. De OpenVPN-ontwikkelaars waarschuwen tegen de gewoonte om nobody als algemeen voorbeeld te gebruiken, omdat andere diensten op de host er misschien al onder draaien en de isolatie die u denkt te hebben er niet is.

Functies die de lokale belasting veranderen, zoals data-kanaal-offload of een build die anders linkt, kunnen verschuiven welke handelingen nodig zijn. Neem de kaart opnieuw door wanneer het pakket verandert, niet alleen wanneer er iets stukgaat.

Schrijf het plan op en behoud hersteltoegang

Een uitrolverslag hoort de manager, de startidentiteit, de bedoelde stabiele identiteit en elke toekenning te noemen, samen met de handeling die ervoor nodig is. Dat verslag maakt de volgende wijziging beoordeelbaar in plaats van experimenteel.

Houd consoletoegang beschikbaar terwijl u bewerkt, want een unit die bij het starten faalt is lastig op afstand te repareren. Test een herstart en een volledige herstart voordat u de wijziging af noemt. Een unit die een herstart overleeft, kan alsnog falen voordat het netwerk er is.

Succes is een begrepen levenscyclus met minimale bevoegdheid, niet een proces dat toevallig onder een andere naam dan root draait.