Терминал дахь root, SELinux дор татгалзав: hook яагаад бүтэлгүйтдэг

Та up скриптийг root-оор ажиллуулбал дуусна, гэтэл үйлчилгээ түүнийг дуудахад мөнөөх скрипт бүтэлгүйтдэг. Файлын зөвшөөрөлд юу ч өөрчлөгдөөгүй тул дараагийн байгалийн алхам нь тэдгээрийг дахин сулруулах бөгөөд энэ нь юу ч засдаггүй. SELinux хост дээр шийдвэрлэх хүчин зүйл нь ихэвчлэн процесс хэн бэ гэдэг биш, харин аль домэйнд ажиллаж байгаа нь бөгөөд хязгаарлагдмал домэйн доторх root нь хязгаарлагдмал хэвээр байна.

Нэг команд, хоёр өөр аюулгүй байдлын домэйн

Төрлийн хэрэгжилт нь эх домэйн, зорилтот шошго болон шаардсан үйлдлийг хамт үнэлдэг. Таны терминалын сесс хязгаарлалтгүй эсвэл административ домэйнд ажилладаг ба демон нь өөрийн нэгжид оноогдсон домэйнд ажилладаг. Тиймээс ижил командууд өөр шийдвэр гаргадаг бөгөөд энэ ялгаа нь бодлогын алдаа биш, зориудынх юм.

Тиймээс хоёр ажиллагааг харьцуулах нь зөвхөн тэдний контекстийг харьцуулж байж ашигтай. Ижил командыг бүрхүүлээс болон hook-оос ажиллуул; бүрхүүлийн хувилбар нь бинарь байгаа, аргументууд зөв гэдгийг нотолдог боловч үйлчилгээ түүнийг ажиллуулах эрхтэй эсэхийг юу ч нотолдоггүй. Хоёр аргаар ажиллуулаад зөвхөн гарах кодууд биш, домэйнуудыг харьцуул. Энэ харьцуулалт л бүрхэг зөвшөөрлийн гомдлыг нэг домэйн, нэг шошгын тухай тодорхой асуулт болгоно.

Энэ гэмтлийн сонгодог хэлбэр нь гадаад хэрэгсэл дууддаг туслах юм. hook өөрөө зөвшөөрөгдсөн байж болох ч түүний дууддаг хэрэгсэл нь үйлчилгээний домэйн гүйцэтгэж болохгүй шошготой, эсвэл шошго нь хориглодог хавтас руу бичдэг.

AVC бичлэгийг hook-ийн алдааны хажууд уншина уу

AVC татгалзал нь хэргийг шийддэг талбаруудыг нэрлэдэг: процессын эх контекст, объектын зорилтот контекст, объектын класс болон татгалзсан тодорхой зөвшөөрөл. Онол бүрдүүлэхийн өмнө дөрвийг нь уншина уу, учир нь гүйцэтгэлд татгалзах ба бичихэд татгалзах нь огт өөр засвартай.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

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

Бичлэгийн хажууд бодлогын хувилбар болон гүйцэтгэх файлын яг замыг тэмдэглэ. Нэг түгээлтийн бодлогод гарч буй домэйны нэр нь тэр суулгацын талаарх нотолгоо бөгөөд өөр бүтээц ижил дүрмийг хүргэдэг гэсэн баталгаа биш. Яг энэ контекст нь өөр хүнд таны дүгнэлтийг өөрийн хост дээр давтах боломж олгодог. Үүнгүйгээр бичлэг нь нотолгоо биш, анекдот мэт уншигддаг.

Шошго, тохиргоо эсвэл бодлого: гурван засвар

Эхний засвар нь файлын суулгасан байрлалтай тохирохгүй шошго юм. cp-ээр байранд нь хуулсан эсвэл засварлагчаар бичсэн скрипт нь үйлчилгээний домэйн ашиглаж чадахгүй анхдагч шошготой байж болох бөгөөд хүлээгдэж буй контекстийг сэргээх нь бодлогод огт хүрэлгүйгээр үүнийг засдаг.

Хоёр дахь нь тохиргоо юм. Түгээлт үйлдлийг ажиллуулах дэмжигдсэн арга, туслахын тулд баримтжуулсан хавтас эсвэл үүнийг аль хэдийн зөвшөөрсөн шинэчлэгдсэн бодлогын багц санал болгож болно. Байршил тохиргоогоо дэмжигдсэн рүү өөрчлөх нь бодлого бичихээс хямд бөгөөд шинэчлэлтийг даадаг.

Гурав дахь нь үнэхээр дутуу дүрэм бөгөөд хамгийн сүүлийн арга байх ёстой. Аудитын хэрэгслүүдээр нэр дэвшигч үүсгэж, юуг үнэхээр зөвшөөрч байгааг уншиж, ажигласан үйлдэл, домэйндоо хүртэл нарийсгаж, үйлдвэрлэлд ойртохын өмнө өөр хүнээр хянуул.

Хуучин allow модуль яагаад хариулт биш

Энэ гэмтлийн хайлтын үр дүн бэлэн модулиар дүүрэн бөгөөд ихэвчлэн hook дахиж дууддаггүй хэрэгслийн хувьд. Нэгийг суулгах нь таны татгалзалтай ямар ч холбоогүй байж болох зөвшөөрөл олгож, байнгын цоорхой нэмэхдээ жинхэнэ зөрүүг байранд нь үлдээдэг.

Энэ нь дараагийн бүтэлгүйтлийг ч нуудаг. Үйлдлийн өргөн ангиллыг зөвшөөрдөг модуль энэ алдааг арилгаж, дараагийн алдааг хэнд хамааруулахыг хамаагүй хэцүү болгоно. Модулийг дараа нь хасах нь бас хэн ч төлөвлөхийг хүсдэггүй өөрчлөлт тул товч зам нь байнгын болох хандлагатай.

Сахилга баттай харьцуулалт нь таны уншиж чадах татгалзал ба таны санал болгож буй өөрчлөлтийн хооронд байна. Red Hat-ийн SELinux-ийн асуудлыг шийдвэрлэх гарын авлага шошгололт болон тохиргооны шалгалтыг үүсгэсэн бодлогын өмнө тавьдаг нь яг энэ шалтгаанаар юм. Хэрэв бичлэгт тохирох татгалзал байхгүй бол SELinux магадгүй таны асуудал биш бөгөөд зам, sandbox эсвэл зөвшөөрлийн асуудлууд хараахан нээлттэй байна.