သီးခြားကွန်တိန်နာများမှ လွတ်မြောက်ရန် အသုံးပြုနိုင်သည့် Linux kernel ရှိ cgroups v2022 အရင်းအမြစ်ကန့်သတ်မှု ယန္တရားအား အကောင်အထည်ဖော်ရာတွင် အားနည်းချက်တစ်ခု (CVE-0492-1) ၏အသေးစိတ်အချက်အလက်များကို ထုတ်ဖော်ခဲ့သည်။ Linux kernel 2.6.24 ကတည်းက ပြဿနာရှိနေခဲ့ပြီး kernel ထုတ်ဝေမှုများ 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 ဖိုင်ကိုင်တွယ်သူရှိ လော့ဂျစ်အမှားတစ်ခုကြောင့်ဖြစ်သည်။ cgroup ရှိ လုပ်ငန်းစဉ်ကို ရပ်စဲလိုက်သောအခါ kernel မှ လုပ်ဆောင်မည့် ပရိုဂရမ်အား release_agent ဖိုင်ကို သတ်မှတ်ရန် အသုံးပြုပါသည်။ ဤပရိုဂရမ်သည် root namespace တွင် "စွမ်းရည်" အားလုံးဖြင့်အလုပ်လုပ်သည်။ စီမံခန့်ခွဲသူသာလျှင် release_agent ဆက်တင်သို့ ဝင်ရောက်ခွင့်ရှိသည်ဟု ယူဆရသော်လည်း လက်တွေ့တွင်မူ စစ်ဆေးမှုများသည် ကွန်တိန်နာမှ ပြောင်းလဲခြင်း သို့မဟုတ် စီမံခန့်ခွဲခွင့်မရှိသော အမြစ်အသုံးပြုသူမှ ဆက်တင်ကို မဖယ်ထားဘဲ အရင်းအသုံးပြုသူအား ဝင်ရောက်ခွင့်ပေးရန် ကန့်သတ်ထားသည် (CAP_SYS_ADMIN )
ယခင်က၊ ထိုသို့သောအင်္ဂါရပ်ကို အားနည်းချက်တစ်ခုအဖြစ် ထင်မြင်လာမည်မဟုတ်သော်လည်း၊ အသုံးပြုသူအမည်နေရာများ (အသုံးပြုသူအမည်နေရာများ) ထွန်းကားလာသောအခါတွင် သင့်အား root အသုံးပြုသူနှင့် ထပ်မထပ်သည့်ကွန်တိန်နာများတွင် သီးခြား root အသုံးပြုသူများကို ဖန်တီးနိုင်စေမည့် အခြေအနေသို့ ပြောင်းလဲသွားခဲ့သည်။ အဓိကပတ်ဝန်းကျင်။ ထို့ကြောင့်၊ တိုက်ခိုက်မှုတစ်ခုအတွက်၊ ၎င်း၏ကိုယ်ပိုင် root အသုံးပြုသူပါရှိသော ကွန်တိန်နာတစ်ခုတွင် သင်၏ release_agent ကိုင်တွယ်သူကို ချိတ်ဆက်ရန် လုံလောက်ပါသည်။ လုပ်ငန်းစဉ်ပြီးပါက၊ လုပ်ငန်းစဉ်ပြီးပါက ပင်မပတ်ဝန်းကျင်၏ အခွင့်ထူးများအပြည့်ဖြင့် လုပ်ဆောင်သွားမည်ဖြစ်ပါသည်။
မူရင်းအားဖြင့်၊ cgroupfs များကို ဖတ်ရန်-သပ်သပ်မုဒ်တွင် ကွန်တိန်နာတစ်ခုတွင် တပ်ဆင်ထားသော်လည်း သင့်တွင် CAP_SYS_ADMIN လုပ်ပိုင်ခွင့်များရှိပါက သို့မဟုတ် သီးခြားအသုံးပြုသူအမည်အာကာသဖြင့် ခွဲဝေခြင်းမရှိသည့်စနစ်ခေါ်ဆိုမှုကို အသုံးပြု၍ ဤ pseudofs များကို ရေးမုဒ်တွင် ပြန်လည်တပ်ဆင်ရာတွင် ပြဿနာမရှိပေ။ ဖန်တီးထားသော ကွန်တိန်နာအတွက် CAP_SYS_ADMIN လုပ်ပိုင်ခွင့်များ ရနိုင်ပါသည်။
သီးခြားကွန်တိန်နာတစ်ခုတွင် သို့မဟုတ် နောက်ထပ်အခွင့်ထူးများရယူခြင်းကို တားမြစ်ထားသည့် no_new_privs အလံမပါဘဲ ကွန်တိန်နာကိုဖွင့်သည့်အခါတွင် သင့်တွင် root အခွင့်ထူးများရှိပါက တိုက်ခိုက်မှုကို လုပ်ဆောင်နိုင်သည်။ စနစ်တွင် အသုံးပြုသူ namespaces ကို ဖွင့်ထားရန် ပံ့ပိုးမှု ရှိရပါမည် ( Ubuntu နှင့် Fedora တွင် မူရင်းအတိုင်း ဖွင့်ထားသော်လည်း Debian နှင့် RHEL တွင် မဖွင့်ထားပါ) နှင့် root cgroup v1 သို့ ဝင်ရောက်ခွင့်ရှိသည် (ဥပမာ၊ Docker သည် root RDMA cgroup တွင် ကွန်တိန်နာများကို လုပ်ဆောင်သည်)။ သင့်တွင် CAP_SYS_ADMIN အခွင့်ထူးများရှိပါကလည်း တိုက်ခိုက်မှုဖြစ်နိုင်သည်၊ ယင်းအခြေအနေတွင် အသုံးပြုသူအမည်နေရာလွတ်များအတွက် ပံ့ပိုးမှုနှင့် cgroup v1 အမြစ်အဆင့်သို့ဝင်ရောက်ခွင့်မလိုအပ်ပါ။
သီးခြားကွန်တိန်နာမှ လွတ်မြောက်ခြင်းအပြင်၊ အားနည်းချက်သည် "စွမ်းရည်များ" မပါဘဲ အမြစ်အသုံးပြုသူတစ်ဦးမှ စတင်သည့် လုပ်ငန်းစဉ်များကို ခွင့်ပြုပေးသည် သို့မဟုတ် CAP_DAC_OVERRIDE လုပ်ပိုင်ခွင့်ရှိသည့် မည်သည့်အသုံးပြုသူမဆို (တိုက်ခိုက်မှုသည် ဖိုင် /sys/fs/cgroup/*/release_agent သို့ ဝင်ရောက်ခွင့် လိုအပ်ပါသည်။ root မှပိုင်ဆိုင်သည်) စနစ်ကျသော "စွမ်းရည်များ" အားလုံးကိုဝင်ရောက်ခွင့်ရရှိရန်။
Seccomp သည် unshare() စနစ်ခေါ်ဆိုမှုသို့ ဝင်ရောက်ခွင့်ကို ပိတ်ဆို့ထားသောကြောင့် Seccomp၊ AppArmor သို့မဟုတ် SELinux ကာကွယ်ရေးယန္တရားများကို အသုံးပြုသည့်အခါတွင် အားနည်းချက်ကို အသုံးချ၍မရနိုင်ကြောင်း မှတ်သားထားရသည်။
source: opennet.ru