Dosieraj Permesoj en Linukso

Saluton al ĉiuj. Ni aktive eklaboras kaj jam preparas multajn potencajn lanĉojn en januaro. Inter aliaj, aliĝo estis anoncita por nova fluo de ĉies ŝatata kurso. "Linuksa Administranto". Antaŭ la lanĉo, ni tradicie dividas tradukojn de utila materialo.

Dosieraj Permesoj en Linukso

Dosieraj permesoj ofertas sekuran alternativon al SUID-efektivaĵoj, sed povas ŝajni iomete konfuzaj komence.


Ni ĉiuj scias ke binaroj SUID estas la malbona decido el sekureca vidpunkto. Feliĉe, se via aplikaĵo postulas kelkajn limigitajn privilegiojn, ekzistas pli efika maniero nomita dosieraj permesoj.

Mi ŝparos al vi iom da tempo, se vi volas eviti detale legi la supran artikolon: Esence, dosieraj permesoj permesas procezojn, kiuj funkcias kiel radiko kaj tial rajtas fari ion por reteni certajn kapablojn, limigitajn. ĉi tiu listokiam ili faligas privilegiojn kaj estas prizorgataj de senprivilegia uzanto. Ĉi tio signifas, ke se atakanto sukcesas kompromiti procezon uzante bufran superfluon aŭ alian ekspluaton, ili ne povos utiligi ion alian ol certajn minimumajn privilegiojn, kiujn la procezo efektive bezonas.

Permesoj estas bonegaj por servoj, kiuj kutime funkcias kiel radiko, sed kio pri komandliniaj utilecoj? Feliĉe, ĉi tio ankaŭ estas subtenata kondiĉe ke vi havas la ĝustajn ilojn instalitajn. Se vi uzas Ubuntu, vi ekzemple bezonos la pakaĵon libcap2-bin. Vi ankaŭ devos ruli ne-arkaikan kernon (el versio 2.6.24).

Ĉi tiuj funkcioj permesas permesojn esti asociitaj kun ruleblaj dosieroj, simile al fiksado de la SUID-bito, sed nur por specifa aro de permesoj. Utilo setcap uzata por aldoni kaj forigi permesojn de dosiero.

La unua paŝo estas elekti la permesojn, kiujn vi bezonas. Por ĉi tiu artikolo, mi supozas, ke ekzistas retdiagnoza ilo nomata tracewalk, kiu devus povi uzi krudaj ingoj. Ĉi tio kutime postulas, ke la aplikaĵo estu rulita kiel radiko, sed dum spektado la listo rezultas, ke necesas nur permeso CAP_NET_RAW.

Supozante, ke vi estas en la dosierujo, kie troviĝas la binaro tracewalk, vi povas aldoni ĉi tiun permeson tiel:

sudo setcap cap_net_raw=eip tracewalk

Ignoru la sufikson por nun =eip por rezolucio, mi parolos pri tio post kelkaj sekundoj. Notu, ke la permesnomo estas minuskla. Vi nun povas kontroli ĉu vi ĝuste agordis permesojn per:

setcap -v cap_new_raw=eip tracewalk

Aŭ vi povas listigi ĉiujn permesojn fiksitajn por antaŭfiksita rulebla:

getcap tracewalk

Por referenco, vi ankaŭ povas forigi ĉiujn permesojn de la plenumebla per:

setcap -r tracewalk

Je ĉi tiu punkto, vi devus povi ruli la ruleblan kiel senprivilegia uzanto, kaj ĝi devus povi labori kun krudaj ingoj, sed ne havi iujn ajn el la aliaj privilegioj kiujn la radika uzanto havas.

Kion do signifas ĉi tiu stranga sufikso? =eip? Ĉi tio postulas iom da kompreno pri la naturo de permesoj. Ĉiu procezo havas tri arojn da permesoj − efika, hereda kaj permesita:

  • Efika Permesoj estas tiuj kiuj difinas kion procezo povas efektive fari. Ekzemple, ĝi ne povas trakti krudajn ingojn se CAP_NET_RAW ne estas en la efika aro.
  • Disponebla permesoj estas tiuj, kiujn procezo rajtas havi se ĝi petas ilin uzante la taŭgan vokon. Ili malhelpas procezon fari ion ajn krom se ĝi estis specife skribita por peti koncernan permeson. Tio permesas al procezoj esti skribitaj por aldoni kritikajn permesojn al la efika aro nur por la periodo kiam ili estas fakte postulataj.
  • Heredebla permesoj estas tiuj, kiuj povas esti hereditaj en la alirebla aro de la generita infana procezo. Dum kirurgio fork()clone() la infanprocezo ĉiam ricevas kopion de la permesoj de la gepatra procezo ĉar ĝi daŭre funkcias la saman ruleblan ĉe tiu punkto. Heredebla aro estas uzata kiam exec() (aŭ ekvivalento) estas vokita por anstataŭigi la ruleblan dosieron per alia. Je ĉi tiu punkto, la disponebla aro de la procezo estas maskita de la hereda aro por akiri la alireblan aron, kiu estos uzata por la nova procezo.

Do la utileco setcap permesas al ni aldoni la permesojn de ĉi tiuj tri aroj sendepende por antaŭfiksita rulebla. Notu, ke la signifo de grupoj estas iomete malsame interpretita por dosierpermesoj:

  • Disponebla dosierpermesoj estas tiuj, kiuj estas ĉiam haveblaj al plenumebla dosiero, eĉ se la gepatra procezo kiu vokis ĝin ne havis ilin. Ili antaŭe estis nomitaj "devigitaj" permesiloj.
  • Heredita dosierpermesoj difinas kroman maskon kiu ankaŭ povas esti uzata por forigi permesojn de la aro de la alvoka procezo. Ili validas aldone al la heredita aro de la alvoka procezo, do la permeso estas heredita nur se ĝi ekzistas en ambaŭ aroj.
  • Efika dosieraj permesoj estas fakte nur unu bito, ne aro, kaj se agordita, tio signifas, ke la tuta disponebla aro ankaŭ estas kopiita en la efikan aron de la nova procezo. Ĉi tio povas esti uzata por aldoni permesojn al procezoj, kiuj ne estis specife skribitaj por peti ilin. Ĉar ĝi estas unu bita, se vi agordas ĝin por iu ajn permeso, ĝi devas esti agordita por ĉiuj permesoj. Vi povas pensi pri ĝi kiel hereda peco ĉar ĝi estas uzata por permesi permesojn esti uzataj de aplikoj kiuj ne subtenas ilin.

Kiam oni specifas permesojn per setcap tri literoj e, i и p raporti al efika, hereda kaj alirebla aroj respektive. Do, la pli frua specifo:

sudo setcap cap_net_raw=eip tracewalk

...indikas ke la rezolucio CAP_NET_RAW devas esti aldonita al la disponeblaj kaj heredaj aroj kaj ke la efika bito ankaŭ devas esti agordita. Ĉi tio anstataŭigos ajnajn antaŭe fiksitajn permesojn sur la dosiero. Por agordi plurajn permesojn samtempe, uzu liston per komoj:

sudo setcap cap_net_admin,cap_net_raw=eip tracewalk

Gvidilo pri Permesiloj diskutas ĉion ĉi pli detale, sed espereble ĉi tiu afiŝo iom malmitigis tion, kio okazas. Estas nur kelkaj avertoj kaj lertaĵoj por mencii.

Unue, dosiero-kapabloj ne funkcias kun simbolligiloj - vi devas apliki ilin al la binara dosiero mem (t.e. la celo de la simbolligo).

Due, ili ne funkcias kun interpretitaj skriptoj. Ekzemple, se vi havas Python-skripton al kiu vi volas asigni permeson, vi devas asigni ĝin al la Python-interpretilo mem. Evidente ĉi tio estas ebla sekureca problemo ĉar tiam ĉiuj skriptoj ekzekutitaj per tiu interpretisto havos la specifitan permeson, kvankam ĉi tio ankoraŭ estas signife pli bona ol fari ĝin SUID. La plej ofta solvo ŝajnas esti skribi apartan ruleblan en C aŭ ekvivalento kiu povas plenumi la necesajn operaciojn kaj voki ĝin de skripto. Ĉi tio estas simila al la aliro uzita de Wireshark kiu uzas binaron /usr/bin/dumpcap fari privilegiajn operaciojn:

$ getcap /usr/bin/dumpcap 
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

Trie, dosieraj permesoj estas malŝaltitaj se vi uzas mediovariablon LD_LIBRARY_PATH pro evidentaj sekurecaj kialoj(1). La sama validas por LD_PRELOAD, kiom mi scias.

1. Ĉar atakanto povas evidente anstataŭigi unu el la normaj bibliotekoj kaj uzi LD_LIBRARY_PATHdevigi ĝian bibliotekon esti vokita prefere al la sistema unu, kaj tial havi sian propran arbitran kodon ekzekutita kun la samaj privilegioj kiel la alvokanta aplikaĵo.

Tio estas ĉio. Pliaj detaloj pri la kursprogramo troveblas ĉe retseminario, kiu okazos la 24-an de januaro.

fonto: www.habr.com

Aldoni komenton