Mos i grumbullo fortesimin e systemd mbi rënien user të OpenVPN

Dy receta me privilegje minimale të ngjitura së bashku nuk prodhojnë një vendosje më të rreptë. Një model e lë daemonin të nisë me privilegje dhe të zbresë në një llogari pa privilegje pas inicializimit; tjetri e lë menaxherin e shërbimit ta nisë atë nën një identitet të kufizuar që nga udhëzimi i parë. Secili funksionon vetë, dhe kombinimi shpesh prodhon një shërbim që nuk arrin të bëjë pastër asnjërën nga dy punët. Pjesa tjetër e kalon vendimin me radhë.

Dy modele, një pronar i ndryshimit

Modeli i parë i përket daemonit. Opsionet OpenVPN të komunitetit user dhe group ndryshojnë identitetin pasi tuneli dhe çelësat janë vendosur, dhe persist-key bashkë me persist-tun i mbajnë ato burime të përdorshme më pas.

Modeli i dytë i përket menaxherit të shërbimit. Një rregullim systemd User= ose Group= vendos identitetin nën të cilin nis procesi, dhe direktivat e aftësive vendosin çfarë mund të mbajë. Zgjedhja midis modeleve është çështje paketimi përpara se të jetë çështje sigurie, dhe mirëmbajtësi i paketës tashmë i është përgjigjur. Detyra juaj është ta gjeni atë përgjigje, jo të shpikni një opsion të tretë.

Të dyja janë legjitime. Gabimi është t'i trajtoni si shtresa të një dizajni, sepse modeli i dytë mund ta kthejë ndryshimin e identitetit të të parit në një operacion që procesi nuk lejohet më ta kryejë.

Vendosni ku ndryshon identiteti

Nëse njësia tashmë nis si një llogari e dedikuar, shtimi i një udhëzimi për daemonin që të bëhet llogari tjetër kërkon një tranzicion setuid që një shërbim i forcuar nuk duhej ta bënte kurrë. Dështimi shfaqet si gabim leje në nisje, jo si mesazh i qartë politike. Kjo lexohet si një aftësi që mungon, gjë që i shtyn njerëzit drejt një grupi më të gjerë kufizimesh në vend të pyetjes së identitetit.

Lexoni çfarë ofron vërtet paketa e instaluar përpara se të ndryshoni diçka, përfshirë drejtorinë e saj drop-in. Disa njësi e lënë me qëllim rënien e vetë daemonit sepse menaxheri merret tashmë me të, dhe të tjera mbështeten te ato opsione për ndryshimin pas inicializimit. Heqja e njërës prej tyre pa e ditur cilin model keni trashëguar është mënyra se si një shërbim që funksionon ndalon së nisuri.

Shkruani modelin e zgjedhur në një rresht: në pronësi të menaxherit ose të daemonit. Çdo direktivë e mëvonshme duhet të jetë në përputhje me atë fjali, dhe një njësi e përzier duhet trajtuar si defekt dhe jo si kompromis.

Aftësitë janë kufij, jo dhurata

Një grup kufizimesh aftësish thotë çfarë mund të mbajë një proces më së shumti. Është një tavan, dhe renditja e një aftësie atje nuk jep asgjë në vetvete, prandaj një njësi me grup kufizimesh bujar mund të mos arrijë të krijojë një tunel.

Ajo që vërtet e vendos një aftësi në grupin rrethues të një shërbimi është AmbientCapabilities=. referenca e ekzekutimit të systemd i dokumenton të dyja direktivat veçmas, dhe ky dallim shpjegon pjesën më të madhe të këshillave konfuze për aftësitë në internet.

Shtoni një aftësi vetëm pasi operacioni që dështon ta ketë identifikuar. Një grup kufizimesh më i gjerë fsheh shkakun e vërtetë dhe e lë shërbimin më të privilegjuar se sa synonte dizajni. E bën njësinë edhe më të vështirë për t'u rishikuar, sepse tavani nuk e përshkruan më punën. Hiqni aftësinë shtesë pasi defekti i vërtetë të jetë rregulluar.

Hartoni autoritetin përgjatë ciklit të jetës

Listoni çfarë duhet të bëjë procesi në çdo fazë: nisje, gjendje e qëndrueshme, riautentikim dhe çmontim. Krijimi i ndërfaqes, ndryshimet e rrugëve, leximi i një çelësi të mbrojtur dhe thirrja e një ndihmësi nuk ndodhin të gjitha në të njëjtin moment ose me të njëjtat kërkesa. Renditni listën sipas fazës përpara se ta renditni sipas aftësisë.

Opsionet e qëndrueshmërisë i ruajnë burimet përgjatë rinegocimit, dhe nuk japin leje që nuk janë mbajtur kurrë. Një çelës që procesi nuk mund ta lexojë në nisje do të mbetet i palexueshëm edhe më pas, çfarëdo që thonë flamujt e qëndrueshmërisë. Flamujt ruajnë atë që funksiononte tashmë.

Përdorni një llogari të dedikuar, jo një të përbashkët. Zhvilluesit e OpenVPN paralajmërojnë kundër zakonit të përdorimit të nobody si shembull i përgjithshëm, sepse shërbime të tjera në host mund të ekzekutohen tashmë me atë llogari dhe izolimi që mendoni se keni nuk është aty.

Veçoritë që ndryshojnë ngarkesën lokale, si shkarkimi i kanalit të të dhënave ose një ndërtim që lidhet ndryshe, mund të zhvendosin cilat operacione nevojiten. Rishikoni hartën kur ndryshon paketa, jo vetëm kur diçka prishet.

Shkruani planin dhe mbani aksesin e rikuperimit

Një regjistër vendosjeje duhet të përmendë menaxherin, identitetin e nisjes, identitetin e synuar të qëndrueshëm dhe çdo dhënie bashkë me operacionin që e kërkon. Ai regjistër është ai që e bën ndryshimin e radhës të rishikueshëm në vend të eksperimental.

Mbani aksesin në konsolë të disponueshëm ndërsa redaktoni, sepse një njësi që dështon në nisje është e vështirë të riparohet nga distanca. Provoni një rinisje dhe një rinisje të plotë përpara se ta shpallni ndryshimin të përfunduar. Një njësi që i mbijeton një rinisjeje mund të dështojë ende përpara se rrjeti të jetë lart.

Suksesi është një cikël jete me autoritet minimal i kuptuar, jo një proces që ndodh të ekzekutohet nën një emër që nuk është root.