Ne stakigu systemd-malfermiĝon sur la user-falon de OpenVPN

Du receptoj de minimuma privilegio algluitaj kune ne produktas pli striktan deplojon. Unu modelo lasas la demonon starti kun privilegioj kaj malleviĝi al senprivilegia konto post la pravalorigado; la alia lasas la servan administrilon lanĉi ĝin sub limigita identeco ekde la unua instrukcio. Ĉiu funkcias sola, kaj la kombino ofte produktas servon, kiu povas plenumi nek unu nek la alian taskon pure. La resto de ĉi tio trapasas la decidon laŭorde.

Du modeloj, unu posedanto de la ŝanĝo

La unua modelo apartenas al la demono. La komunuma versio de OpenVPN havas la opciojn user kaj group, kiuj ŝanĝas identecon post kiam la tunelo kaj ŝlosiloj estas starigitaj, kaj persist-key kune kun persist-tun konservas tiujn rimedojn uzeblaj poste.

La dua modelo apartenas al la serva administrilo. systemd-agordo User= aŭ Group= decidas la identecon sub kiu la procezo startas, kaj kapablocifonoj decidas kion ĝi rajtas teni. Elekti inter la modeloj estas paka demando antaŭ ol sekureca demando, kaj la pakaĵprizorganto jam respondis ĝin. Via tasko estas trovi tiun respondon anstataŭ elpensi trian opcion.

Ambaŭ estas legitimaj. La eraro estas trakti ilin kiel tavolojn de unu dezajno, ĉar la dua modelo povas igi la identecŝanĝon de la unua operacio, kiun la procezo jam ne rajtas plenumi.

Decidu, kie la identeco ŝanĝiĝas

Se la unuo jam startas kiel dediĉita konto, aldoni demonan instrukcion fariĝi alia konto postulas setuid-transiron, kiun malmoligita servo neniam celis fari. La fiasko aperas kiel permesa eraro ĉe starto anstataŭ kiel klara politika mesaĝo. Ĝi legiĝas kiel mankanta kapablo, kio puŝas homojn al pli vasta limiga aro anstataŭ al la identeca demando.

Legu, kion la instalita pakaĵo efektive liveras antaŭ ol redakti ion ajn, inkluzive ĝian drop-in-dosierujon. Iuj unuoj intence preterlasas la propran falon de la demono, ĉar la administrilo jam pritraktas ĝin, kaj iuj fidas tiujn opciojn por la ŝanĝo post pravalorigado. Forigi iun ajn el ili sen scii, kiun modelon vi heredis, estas la maniero kiel funkcianta servo ĉesas starti.

Skribu la elektitan modelon en unu linio: administrila aŭ demona. Ĉiu posta cifono devas esti kongrua kun tiu frazo, kaj miksita unuo estu traktata kiel cimo, ne kiel kompromiso.

Kapabloj estas limoj, ne donacoj

Kapabla limiga aro diras, kion procezo rajtas teni plej multe. Ĝi estas plafono, kaj listigi kapablon tie donas nenion per si mem, tial unuo kun malavara limiga aro povas tamen malsukcesi krei tunelon.

Tio, kio efektive metas kapablon en la ĉirkaŭan aron de servo, estas AmbientCapabilities=. La systemd-plenumada referenco dokumentas la du cifonojn aparte, kaj tiu distingo klarigas la plejparton de la konfuzaj kapablokonsiloj en la reto.

Aldonu kapablon nur post kiam la malsukcesanta operacio identigis ĝin. Pli vasta limiga aro kaŝas la veran kaŭzon kaj lasas la servon pli privilegia ol la dezajno intencis. Ĝi ankaŭ malfaciligas revizii la unuon, ĉar la plafono jam ne priskribas la taskon. Forigu la plian kapablon post kiam la vera difekto estas riparita.

Mapigu aŭtoritaton tra la vivciklo

Listigu, kion la procezo devas fari en ĉiu stadio: starto, stabila stato, reaŭtentigo kaj malmuntado. Kreado de interfaco, ŝanĝoj de itineroj, legado de protektita ŝlosilo kaj voko de helpanto ne ĉiuj okazas sammomente aŭ sub la samaj postuloj. Ordigi la liston laŭ stadio antaŭ ol ordigi ĝin laŭ kapablo.

Persistaj opcioj konservas rimedojn tra renegocado, kaj ili ne donas permesojn, kiuj neniam estis tenitaj. Ŝlosilo, kiun la procezo ne povas legi ĉe starto, restos nelegebla ankaŭ poste, kion ajn diras la persistaj flagoj. La flagoj konservas tion, kio jam funkciis.

Uzu dediĉitan konton anstataŭ komunan. La programistoj de OpenVPN admonas kontraŭ la kutimo uzi nobody kiel ĝeneralan ekzemplon, ĉar aliaj servoj sur la gastiganto eble jam funkcias sub tiu konto kaj la izolado, kiun vi pensas havi, ne ekzistas.

Trajtoj, kiuj ŝanĝas la lokan ŝarĝon, kiel datumkanala malŝarĝo aŭ konstruo, kiu ligiĝas alimaniere, povas ŝovi, kiuj operacioj necesas. Revizitu la mapon kiam la pakaĵo ŝanĝiĝas, ne nur kiam io rompiĝas.

Skribu la planon kaj konservu reakiran aliron

Deploa protokolo devus nomi la administrilon, la startan identecon, la celatan stabilan identecon kaj ĉiun donacon kune kun la operacio, kiu postulas ĝin. Tiu protokolo estas tio, kio igas la sekvan ŝanĝon revidebla anstataŭ eksperimenta.

Tenu konzolan aliron disponebla dum vi redaktas, ĉar unuon, kiu fiaskas ĉe starto, estas malfacile ripari malproksime. Testu restartigon kaj plenan restartigon antaŭ ol nomi la ŝanĝon kompleta. Unuo, kiu postvivas restartigon, povas tamen fiaski antaŭ ol la reto estas supre.

Sukceso estas komprenita vivciklo de minimuma aŭtoritato, ne procezo, kiu hazarde funkcias sub ne-radika nomo.