PAM баталгаажуулалт гараар ажилладаг ч OpenVPN үйлчилгээ болж бүтэлгүйтдэг

PAM-аар дамжуулан баталгаажуулалт нь клиентийг гараар ажиллуулахад амжилттай болж, systemd ижил профайлыг эхлүүлэхэд AUTH_FAILED-тэй бүтэлгүйтэж болно. Эдгээр ажиллагааны хооронд нууц үг өөрчлөгдөхгүй; өөрчлөгддөг зүйл нь PAM-аас асуулт асууж буй процессын эргэн тойрны хязгаарлалтын багц юм. PAM өөрийн итгэмжлэлийг өөрчлөх чадвартай туслах програмаар хариулдаг бөгөөд хатууруулсан unit яг энэ чадварыг арилгадаг. Боломжийн жагсаалтад хүрэхээс өмнө тэр туслах програм болон түүнд хэрэгтэй хязгаарыг олоорой.

unix_chkpwd бол PAM-ын асуултад хариулдаг хоёртын файл

Орон нутгийн нууц үгийн баталгаажуулалтаар pam_unix hash файлыг өөрөө ховор уншдаг. Энэ нь unix_chkpwd-г ажиллуулдаг бөгөөд дистрибутивууд үүнийг setuid root эсвэл setgid shadow хэлбэрээр суулгадаг тул /etc/shadow-г унших ямар ч ажилгүй процессын өмнөөс нэг нууц үгийг шалгах боломжтой болдог. Тэр таних тэмдгийг олж авах чадварыг хасвал туслах програм шалгалтыг дуусгаж чадахгүй, тиймээс модуль энгийн баталгаажуулалтын алдаа буцаана.

Дараа нь алдаа нь клиентийн харж болох бүх логт итгэмжлэлийн асуудал мэт харагдана. Энэ бол урхи: клиент PAM түүнд юу хэлснийг мэдээлдэг, PAM зөвхөн стек «үгүй» гэснийг мэдээлдэг. Туслах програмыг root-оор гараар ажиллуулах нь ч юу ч батлахгүй, учир нь энэ нь үйлчилгээ хэзээ ч ашигладаггүй давуу эрхийн замыг туршдаг. systemd-ийн бодитоор ачаалсан unit-ыг уншиж, дараа нь хийсэн оролдлогын системийн логийг уншина уу. Эдгээр хоёр харц нь sandbox-ийн асуудлыг буруу нууц үгийн асуудлаас тусгаарладаг.

Нууц үгийн логийг уншихаас өмнө unit-ыг уншина уу

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

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Эхний команд нь unit болон түүний drop-in-ууд хаанаас ирдэгийг харуулдаг бөгөөд энэ нь чухал, учир нь сарын өмнө нэмсэн дарж бичилт яагаад байгааг санах ойгоос илүү удаан амьдардаг. Хоёр дахь нь дараагийн хоёр хэсэг хамааралтай sandbox утгуудыг хэвлэдэг.

Харж байгаа зүйлээ ижил дистрибутив, хувилбарын ажиллаж буй хосттой харьцуулна уу. User, CapabilityBoundingSet эсвэл NoNewPrivileges дахь ялгаа нь тодорхой ул мөр; зохиолын тайлбар дахь ялгаа нь тийм биш. Ямар нэг зүйлийг өөрчлөхөөс өмнө утгуудыг бичиж аваарай, учир нь хөдөлж буй зорилттой дараагийн харьцуулалт юу ч батлахгүй. Хэрэв үйлчилгээ хоосон bounding багцтай, давуу эрхгүй бүртгэлээр ажиллаж байвал туслах програмд ажиллах юм бараг байхгүй.

Итгэмжлэлийн хувиргалт, файлын хандалт, бодлого гэсэн гурван хязгаар

exec-ийн үед болох зүйлээс эхэл. setuid хоёртын файл эсвэл файлын боломж бүхий файл итгэмжлэлийн хувиргалт үүсгэдэг тул үүссэн таних тэмдэг нь дуудагчийн үргэлжлэл биш. Bounding багц нь ийм файл юу олж авахыг хязгаарлаж, NoNewPrivileges нь setuid, setgid, файлын боломжийн олдворыг бүрэн блоклодог. Эдгээрийн аль нэг нь туслах програмыг зогсоож болох бөгөөд үйлчилгээний бусад бүх функц хэвээр үлдэнэ.

Дараа нь өргөн дискрецион тойрч гарах замыг нарийн унших хандалтаас тусгаарла. CAP_DAC_OVERRIDE дискрецион шалгалтыг бараг хаа сайгүй алгасдаг бол CAP_DAC_READ_SEARCH өөрийн нэмэлт эрх мэдэлтэйгээр уншилт, хавтас дамжилтыг хамардаг. Эдгээр нь өөр нөлөөний радиустай өөр хэрэгслүүд бөгөөд аль нь ч «PAM shadow файлыг уншиг» гэсэн өгүүлбэрийн зөв бичиг биш.

Эцэст нь заавал мөрдөх бодлого энэ үйлдлийг ерөөс зөвшөөрч байгаа эсэхийг асуу. Linux боломж SELinux-ыг хүчингүй болгодоггүй бөгөөд нэгийг эзэмших нь type enforcement дүрмийн талаар юу ч батлахгүй. Файлын хандалтаас татгалзсан ба боломжоос татгалзсаныг өөр нотолгоо гэж үзээрэй, учир нь тэд өөр засварыг, ихэвчлэн өөр эзэмшигчийг нэрлэдэг. Бичлэгийн талбар бүрийг унш, зөвхөн denied гэдэг үгийг биш. Аль гүйцэтгэгдэх файл үйлдлийг хийсэн, ямар домэйн дотор ажилласан, ямар төрлийн зорилтод хүрсэн, ямар объектын анги оролцсон, бодлого ямар зөвшөөрлөөс татгалзсан — тус бүр өөр аргаар хариултыг нарийсгана.

Татгалзлыг аудитын логоос гаргаж ав

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

ausearch -m AVC,USER_AVC -ts recent

Хоосон үр дүн нь гэмгүй байдлын нотолгоо биш. Энэ нь аудит цуглуулдаггүй, эсвэл таны цонх оролдлогыг алгасан гэсэн үг бөгөөд бодлогыг хасахын өмнө хоёуланг нь хасах ёстой.

Red Hat-ын SELinux-ийн алдаа засах удирдамж шошго болон тохиргооны шалгалтыг allow дүрэм үүсгэхээс өмнө тавьдаг бөгөөд энэ нь энэ асуудалд ч зөв дараалал юм. Буруу шошголсон туслах хоёртын файл болон бодлогын цоорхой ижил төстэй татгалзал үүсгэдэг ч өөр засвар шаарддаг. Шошголлын алдаанд allow дүрэм үүсгэх нь гэмтлийг нууж, дараагийн багц шинэчлэлт түүнийг дахин оруулахыг зөвшөөрдөг. Ямар ч бодлого бичихээс өмнө суулгасан туслах програмын шошгыг баталгаажуул.

Нэг хүлээн авсан, нэг татгалзсан нэвтрэлтээр өөрчлөлтийг батал

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

Бодит холболтын оролдлого хийж, дараа нь тэр даруй логийг унш. Засварыг батлах мөр нь тэр оролдлогын pam_unix(openvpn:auth) бичлэг: тэнд баталгаажуулалт амжилттай гэж бичигдсэн байх ёстой бөгөөд ямар ч AVC бичлэг ижил секунд агуулаагүй байх ёстой.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Ажиллаж буй туннель дахин холболт шаарддаг, учир нь sandbox-ийн өөрчлөлт хоёр дахь холболтыг эхнийхээс илүү олон удаа тасалдаг. Дахин холбогдсоны дараа тогтоосон сокетыг шалгаж, ижил unit түүнд үйлчилсээр байгааг батал.