Via VPN-komando funkcias senprivilegie; la servo ne
Neniu pasvorta invito diras ion pri tio, kiu ŝanĝas itinerojn. Trovu la servon, la interfacon, kiun ĝi elmetas, kaj la politikon, kiu decidas, kiuj alvokantoj rajtas peti.
La VPN-komando funkcias kiel via uzanto, neniu pasvorto aperas, kaj la tunelo ekfunkcias. Tiu sinsekvo sentiĝas kiel senprivilegia operacio, kaj kutime ĝi ne estas. Aparta servo plenumas la retajn ŝanĝojn, kaj la interesa demando estas, kion tiu servo faros por alvokanto, kiun ĝi ne kontrolis. Nombri pasvortajn invitojn diras al vi nenion pri tiu limo.
La interfaco, la mekanismo kaj la kontrolo
La interfaco akceptas petojn: konekti, malkonekti, elekti profilon. La mekanismo posedas la retajn operaciojn: krei interfacojn, ŝanĝi itinerojn, apliki filtrilojn. La rajtiga kontrolo decidas, ĉu ĉi tiu alvokanto rajtas peti ĉi tiun agon. Tiuj tri povas esti disigitaj inter duuma dosiero, helpilo kaj sistema servo, kaj la uzanto vidas nur la unuan.
La roloj povas loĝi en unu duuma dosiero, en du procezoj aŭ en kliento kaj sistema servo, kaj la komando, kiun la uzanto vidas, malofte malkaŝas kiun. Piktogramo en la sistempleto kaj sistema demono povas aspekti kiel unu aplikaĵo dum ili funkcias kun tre malsama aŭtoritato. Privilegio ĉe instalado kaj privilegio ĉe peto ankaŭ estas malsamaj aferoj. Instalilo, kiu funkciis kiel root, povas lasi servon aŭskultantan por postaj petoj, longe post kiam la pakaĵadministrilo finiĝis. Tiu servo, ne la komando, kiun vi tajpis, tenas la aŭtoritaton.
Delegado estas la normala dezajno
Delegi privilegian retan laboron al servo estas la racia arkitekturo. Ĝi tenas ordinarajn aplikaĵojn senprivilegiaj, kaj ĝi centralizas la operaciojn, kiuj bezonas zorgon. La dezajno pagas sin nur kiam la servo ankaŭ kontrolas, kiu demandas kaj por kio. Sen tiu kontrolo ĝi estas nur pli larĝa pordo.
NetworkManager estas la konkreta ekzemplo por Linux. Ĝia konfigura gvidilo klarigas, kiel PolicyKit rajtigas petojn, kiuj ne venas de root, en la defaŭlta agordo. Tio montras delegitan rajtigon en reala produkto. Ĝi ne pruvas, ke ĉiu komerca kliento uzas NetworkManager, kaj ĝi ne priskribas la soketan vojon nek la politikon de iu ajn konkreta vendanto.
La ŝablono estas delegado kun politiko malantaŭ ĝi. La ekzemplo estas unu realigo de tiu ŝablono, ne universala.
Legu la limon, ne la inviton
Trovu la servon, la posedanton de ĝia konfiguracio kaj la lokan interfacon, kiun uzas la fasado. Poste demandu, kiuj uzantoj rajtas peti kiujn operaciojn. Povi suprenigi kaj mallevi unu konservitan profilon ne estas la sama permeso kiel ŝargi konfiguracion, kiun la operatoro neniam reviziis. La diferenco estas la tuta sekureca demando.
Komencu per la servoadministrilo kaj per la propra vidpunkto de la kliento pri siaj permesoj. La subaj komandoj montras, ĉu la demono funkcias, kion la alvokanto rajtas peti de ĝi, kaj kion la demono elmetas sub sia rulada dosierujo.
systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager
Demandu ankaŭ, kion la operacio influas. Menuero, kiu aspektas persona, povas ŝanĝi itinerojn kaj DNS por la tuta maŝino, kio signifas, ke ĝi povas perturbi la seancojn de aliaj uzantoj. La efika radiuso apartenas al la sama revizio kiel la permeso, kaj ĝi kutime decidas, ĉu la servo bezonas pli mallarĝan rolon.
Riparu permesojn per la subtenata maniero
Fari protektitan kontrolan soketon skribebla por ĉiuj, aŭ aldoni konton al larĝa administra grupo, forigas permesan eraron kaj kreas pli grandan. La eraro estis la sola afero, kiu diris al vi, ke tiu limo ekzistas. Uzu la dokumentitan membrecan aŭ rajtigan proceduron, inkluzive de la seanca refreŝigo, kiun ĝi postulas. Grupa membreco ofte validas nur por novaj ensalutaj seancoj, kaj tial ŝanĝo povas ŝajni fari nenion ĝis la sekva ensaluto.
Se la produkto elmetas pli mallarĝan rolon por la operacio, preferu ĝin al ĝenerala permeso. Skribu la elektitan rolon kaj ĝian posedanton apud la serva nomo.
Kiel aspektas bona disigo
Ordinaraj aplikaĵoj restas senprivilegiaj, la servo plenumas nur la agordon, por kiu ĝi estis desegnita, kaj ĉiu alvokanto estas kontrolata kontraŭ politiko, kiun iu posedas. Tio estas defendebla dezajno. Ĝi ankaŭ estas reviziebla, ĉar la politiko havas nomon ligitan al ĝi. Io ajn pli granda meritas skriban escepton anstataŭ silenta permesa ŝanĝo.
La malsukcesa reĝimo estas servo, kiu plenumas ĉiun peton de ĉiu loka uzanto ĉar la interfaco estas oportuna. Ĝi aspektas identa de la uzanta flanko, kaj ĝi portas multe pli grandan aŭtoritaton. Testu unu rifuzitan peton, ne nur la sukcesan. Rifuzo, kiu venas de la politiko, estas la pruvo, ke la politiko ekzistas.