обочолонгон контейнерден качууга мүмкүндүк берген v1 топторундагы аялуу

Linux өзөгүндөгү cgroups v2022 ресурстук чектөө механизмин ишке ашыруудагы аялуу (CVE-0492-1) чоо-жайы ачылды, аны изоляцияланган контейнерлерден качуу үчүн колдонсо болот. Көйгөй Linux ядросунун 2.6.24 версиясынан бери бар жана 5.16.12, 5.15.26, 5.10.97, 5.4.177, 4.19.229, 4.14.266 жана 4.9.301 ядро ​​релиздеринде чечилген. Пакет жаңыртууларынын басылмаларын бул баракчаларда бөлүштүрө аласыз: Debian, SUSE, Ubuntu, RHEL, Fedora, Gentoo, Arch Linux.

Алсыздык, иштеткичти толук артыкчылыктар менен иштетүүдө тийиштүү текшерүүлөрдү аткара албаган, release_agent файл иштеткичиндеги логикалык ката менен шартталган. Чыгаруу_агент файлы топтун процесси токтотулганда ядро ​​тарабынан аткарыла турган программаны аныктоо үчүн колдонулат. Бул программа тамыр катары жана тамыр мейкиндигинде бардык "мүмкүнчүлүктөр" менен иштейт. release_agent жөндөөсүнө администратор гана кире алат деп болжолдонгон, бирок чындыгында текшерүүлөр түпкү колдонуучуга кирүү мүмкүнчүлүгүн берүү менен чектелди, бул жөндөө контейнерден же администратордук укугу жок түпкү колдонуучу тарабынан өзгөртүлгөнүн жокко чыгарбайт (CAP_SYS_ADMIN ).

Мурда мындай өзгөчөлүк аялуу катары кабыл алынмак эмес, бирок абал колдонуучулардын аттары мейкиндиктеринин (пайдалануучулардын аттары мейкиндиктери) пайда болушу менен өзгөрдү, алар сиз өзүңүздүн түпкү колдонуучу менен дал келбеген контейнерлерде өзүнчө түпкү колдонуучуларды түзүүгө мүмкүндүк берет. негизги чөйрө. Демек, чабуул үчүн, сиздин release_agent иштеткичиңизди өзүнчө колдонуучу ID мейкиндигинде өзүнүн түпкү колдонуучусу бар контейнерге туташтыруу жетиштүү, ал процесс аяктагандан кийин негизги чөйрөнүн толук артыкчылыктары менен аткарылат.

Демейки боюнча, cgroupfs окуу үчүн гана режимде контейнерге орнотулган, бирок CAP_SYS_ADMIN укуктарыңыз бар болсо же бөлүштүрүүнү токтотуу тутум чалуусунун жардамы менен өзүнчө колдонуучу атын мейкиндиги менен уяланган контейнерди түзүү менен бул псевдофторду жазуу режиминде кайра орнотууда көйгөй жок. CAP_SYS_ADMIN укуктары түзүлгөн контейнер үчүн жеткиликтүү.

обочолонгон контейнерден качууга мүмкүндүк берген v1 топторундагы аялуу

Кол салуу сизде обочолонгон контейнерде тамыр артыкчылыктары бар болсо же кошумча артыкчылыктарды алууга тыюу салган no_new_privs желекчеси жок контейнерди иштетип жатканда жүргүзүлүшү мүмкүн. Системада колдонуучу аттары мейкиндиктери үчүн колдоо болушу керек (Ubuntu жана Fedoraда демейки боюнча иштетилген, бирок Debian жана RHELде иштетилген эмес) жана v1 тамыр cgroup'уна кирүү мүмкүнчүлүгү болушу керек (мисалы, Docker тамыр RDMA cgroup ичиндеги контейнерлерди иштетет). Эгер сизде CAP_SYS_ADMIN артыкчылыктары болсо, чабуул да мүмкүн, мында колдонуучу аттар мейкиндиктерин колдоо жана cgroup v1 тамыр иерархиясына кирүү талап кылынбайт.

Изоляцияланган контейнерден качуудан тышкары, алсыздык "мүмкүнчүлүктөрү" жок түпкү колдонуучу же CAP_DAC_OVERRIDE укуктары бар каалаган колдонуучу тарабынан ишке киргизилген процесстерге жол берет (чабуул /sys/fs/cgroup/*/release_agent файлына кирүү мүмкүнчүлүгүн талап кылат, ал тамырга таандык) бардык системалык "мүмкүнчүлүктөргө" жетүү үчүн.

Контейнерлерди кошумча изоляциялоо үчүн Seccomp, AppArmor же SELinux коргоо механизмдерин колдонууда алсыздыкты колдонуу мүмкүн эместиги белгиленет, анткени Seccomp unshare() тутумунун чалуусуна кирүүгө бөгөт коёт, ал эми AppArmor жана SELinux жазуу режиминде cgroupfs орнотууга уруксат бербейт.

Source: opennet.ru

Комментарий кошуу