OpenVPN дээр chroot бүтэлгүйтэж байна: AppArmor дүрэм эсвэл эрх мөн үү?

Демон chroot-ийн алдааг бичиж, профайл аль хэдийн өргөн харагдаж байна, тиймээс уруу татсан шийдэл нь замын дүрмийг өргөтгөж дахин эхлүүлэх юм. Энэ нь ихэвчлэн юу ч өөрчлөхгүй, учир нь chroot нь профайл хэзээ ч шилжүүлж чадаагүй эрхээр хянагддаг. Аль давхаргад хүрэхийг шийдэхийн тулд гурван хямд шалгалт хэрэгтэй: процесс юу хадгалахыг зөвшөөрдөг, бодлого юу зөвшөөрдөг, эдгээр хоёр чухал болохоос өмнө эхлүүлэгч юу арилгасан.

Хоёр тусдаа хаалга, зөвхөн нэг нь AppArmor-ынх

chroot нь процесс ажиллаж буй хэрэглэгчийн нэрийн орон зайд CAP_SYS_CHROOT шаарддаг. Энэ бол ердийн Linux эрх бөгөөд цөм нь дуудлага замуудтай ямар нэгэн зүйл хийхээс өмнө шалгадаг. Тусдаа, хэрэгжүүлэх AppArmor профайл нь процесс эрхтэй байсан ч үүнийг татгалзаж болно, учир нь заавал мөрдөх бодлого нь итгэмжлэлийн оронд тэдгээрийн хамт авч үздэг. Энэ ялгаа нь практикт чухал: хоёр давхарга өөр файлд амьдардаг бөгөөд ихэвчлэн өөр хүмүүс тэдгээрийг арчилдаг.

Тэр хоёр хаалга ижил errno-оор бүтэлгүйтдэг. Хоёулаа EPERM гаргаж, хоёулаа демоны логт ерөнхий зөвшөөрлийн гомдол болж харагддаг, тиймээс профайлын агуулгыг таамаглах нь маш их цагийг үрдэг. Таны нэмэх гэж байсан замын дүрэм chroot амжилттай болсны дараах файлын хандалтыг хянадаг; үйлдэл ерөнхийдөө зөвшөөрөгдөх эсэхэд түүний хамаа алга.

Гурав дахь хаалга хоёрынхоос дээгүүр байна. Хэрэв үйлчилгээний менежер эсвэл бүрхүүл процессыйг хязгаарлах олонлогт эрхгүйгээр эхлүүлсэн бол ямар ч AppArmor өөрчлөлт үүнийг буцааж чадахгүй, профайлд эрх нэмэх нь цөм хүндэтгэхгүй зорилгыг л баримтжуулна.

Бодлогыг засахын өмнө эрхийн төлөвийг унш

Идэвхтэй гэж бодож буй тохиргооноос биш, ажиллаж буй процессоос эхэл. Төлөвийн файл таван эрхийн маск болон no-new-privileges тугыг илчилдэг бөгөөд тэд өөр асуултад хариулдаг:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff нь дуудлагын хувьд чухал олонлог: CapBnd-д байгаа ч CapEff-д байхгүй эрх нь дээд хязгаараар зөвшөөрөгдсөн боловч одоо эзэмшээгүй байна. CapAmb нь хоёртын файл ердийн setuid утгаар эрхгүй үед чухал, учир нь орчны эрхүүд нь үйлчилгээ файлын эрхгүйгээр exec дамжин эрхээ хадгалах арга юм. CapInh нь exec дамжин өвлөгдөж болох битүүдийг агуулдаг, гэхдээ ажиллуулах файлын өвлөх олонлог зөвшөөрсөн үед л, тиймээс тэнд байгаа нэг бит дангаараа юу ч өгөхгүй.

Дараа нь ямар профайл үнэхээр холбогдсоныг батал. Процесс таны хүлээгээгүй профайлын нэрээр хязгаарлагдсан байж болно, ялангуяа түгээлт өөрийн unit файл болон профайлыг хамт илгээх үед, /proc/PID/attr/current унших нь үүнийг нэг мөрөнд шийднэ. Өөрийн зассан файлыг цөмийн мэдээлж буй профайлтай харьцуулах нь шалтгааныг засах болон хэн ч ачаалахгүй файлыг засах хоорондын ялгаа юм.

Аудитын мөр тийм гэж хэлсэн үед л эрхийн дүрэм нэм

Цөм болон аудитын бичлэгүүд татгалзсан давхаргыг нэрлэдэг. Үйлдэл нь capable, нэр нь sys_chroot гэсэн, түүнийг үүсгэсэн профайлтай хамт татгалзлыг хай. Хэрэв тэр бичлэг байгаа бол процесс эрхийг аль хэдийн эзэмшиж байсан бөгөөд AppArmor татгалзсан, зорилтот өөрчлөлт нь бодит профайл доторх эрхийн дүрэм:

capability sys_chroot,

Үүнийг үнэхээр холбогдсон профайлд хэсэг болгон хадгал, түлхүүр үгийг хамааралгүй заавраас дүрэм хуулахын оронд apparmor.d профайлын лавлагаатай тулгаж шалга. Үүнийг хуваалцсан include дотор хийх нь тэр файлыг татдаг бүх хязгаарлагдсан програмд өгнө, профайлыг complain горимд шилжүүлэх нь энийг шийдэхийн оронд дараагийн татгалзлыг нууна. Профайлын дүрэм бодлогын татгалзлыг арилгадаг; эрх үүсгэдэггүй, тиймээс үр дүнтэй олонлогт CAP_SYS_CHROOT хэзээ ч байгаагүй процесс дүрэм байсан ч бүтэлгүйтнэ.

Хэрэв аудитын бичлэг AppArmor татгалзлыг огт харуулахгүй бол профайлыг засахаа зогсоо. Та итгэмжлэлийн асуудал харж байна, үлдсэн ажил нь unit файл эсвэл эх процесс дотор, бодлогын хэлэнд биш.

Үйлчилгээний менежер өөрийн дээд хязгаарыг хадгалдаг

systemd үйлчилгээ бүрт эрхийн хязгаарлах олонлогыг тогтоодог, анхдагчаар тэр олонлог нарийн. Тэнд хасагдсан бүхэн профайл юу ч гэсэн процессд боломжгүй, тиймээс хатуужуулсан unit-үүд демоныг гараар эхлүүлэхэд ажиллаж байсан үйлдэлд бүтэлгүйтэж болно. Холбогдох зааварчилгааг unit-ээс уншихад хялбар, програм алдаа мэдэгдэх үед анзаарахгүй өнгөрөхөд ч хялбар. Түгээлтийн багц нийлүүлдэг drop-in файлууд нь хэн ч тохируулсанаа санахгүй дээд хязгаарын ердийн эх сурвалж.

Дээд хязгаарыг өргөх, эрх олгох нь нэг биш хоёр өөрчлөлт. Хязгаарлах олонлогын бичлэг процесс эрхийг эзэмшиж болно гэж хэлдэг; энэ нь түүнийг үр дүнтэй олонлогт нэмэхгүй, NoNewPrivs нь бусад бүхэн тохирсон ч дараагийн өргөлт амжилттай болохоос сэргийлж болно. Үйлдэлд хэрэгтэйг л нэм, үлдсэн хатуужуулалтыг хэвээр үлдээ, нэг дуудлага дамжуулахын тулд бүх эрхийг өгөх богино замаас татгалз.

Энд дараалал ч чухал. Эхлээд unit-ийн дээд хязгаарыг өөрчил, CapEff одоо тэр битийг агуулж байгааг батал, дараа нь л AppArmor хэвээр татгалзаж байна уу гэдгийг шийд. Хоёр өөрчлөлтийг зэрэг хийвэл алдаа үргэлжилбэл та дахин таамаглах болно.

Татгалзал арилсны дараа шорон өөрөө шалга

Амжилттай chroot язгуурыг зөөдөг, тиймээс демон дараа нь хүрэх зам бүр шинэ мод дотор шийдэгддэг. Дутуу тохиргоо, байхгүй төхөөрөмжийн зангилаа эсвэл хуулагдаагүй гэрчилгээний хавтас одоо файлын алдаа болж харагдана, тэр алдаа нь эрхийн биш, зохицуулалтын асуудал. Өөр нэг өргөн зөвшөөрөл нэмэхийн оронд дараагийн үйл явдлыг унш. Зөөлт нь харьцангуй замын утгыг ч өөрчилдөг, тиймээс хатуужуулах гарын авлагууд демоны тохиргоонд абсолют зам шаарддаг.

chroot юу хийдэггүйг санах нь ч тустай. Энэ бол замын хил, sandbox биш: эрхээ хадгалсан процесс үүнээс зугтаж чадна, тиймээс эрхийг ихэвчлэн дуудлагын дараа унагадаг, тиймээс хязгаарлалт демоны эргэн тойронд үлдэх ёстой. AppArmor профайл, эрхийн хязгаарлах олонлог, файлын системийн хязгаарлалтыг хамт хадгалах нь энэ дасгалын зорилго, үйлчилгээ эхлэхэд арилгах үлдэгдэл биш.

Шийдлийн дүрэм богино. Аудитын бичлэг AppArmor-ыг нэрлэвэл холбогдсон профайлд нэг эрхийн дүрэм нэм. Үр дүнтэй олонлог хоосон бол unit-ийн дээд хязгаар болон эрх унагах дарааллыг зас. Профайл таны зассан нь биш бол засахаа зогсоож, жинхэнийг нь ол.