SELinux မိတ်ဆက်
နည်းပညာလောကမှာ security နဲ့ တကယ်တန်း ပတ်သတ်လာရင် အုပ်စုနှစ်ဖွဲ့ ပဲရှိပါတယ်။ တစ်ဖွဲ့က InfoSec Professionals တွေနဲ့ နောက်တစ်ဖွဲ့ကတော့ အခြားသောသူတွေပဲဖြစ်ပါတယ်။ ပြောချင်တာက ကိုယ်အနေနဲ့ InfoSec Professional တစ်ယောက်မဟုတ်ဘူးဆိုရင်ဖြင့် security ဆိုတာကြီးကို ဘာမှမဟုတ်သလို နေတတ်ကြပါတယ်။ ဥပမာ တစ်ခုပြောရင် စာရေးသူ တို့တစ်ခုခုကို Windows Server ပေါ်မှာပဲဖြစ်ဖြစ်၊ Linux Server မှာပဲဖြစ် setup လုပ်ပြီးဆိုရင် အကြောင်းအမျိုးမျိုးကြောင့် အလုပ်မလုပ်ဘူးဆိုရင် Firewall တွေကို disable လုပ်တတ်တဲ့ sysadmin တွေရှိပါတယ်။ တကယ်ဆိုရင် အဲ့ဒါဟာ best practice မဟုတ်တဲ့အတွက် လုံးဝကို မလုပ်သင့်ပါဘူး။ သို့သော် စာရေးသူတို့ တခါတခါ အလွယ်သဘောမျိုးနဲ့ ဘာကြောင့်လဲဆိုတာကို မစဉ်းစားတော့ပဲနဲ့၊ ရှိသမျှ system တစ်ခုရဲ့ security shield တွေအကုန်ချလိုက်တတ်ကြပါတယ်။ အထူးသဖြင့် security လို့ဆိုလိုက်ရင် anti-virus software တို့၊ firewall တို့ကိုပဲ မျက်လုံးထဲမြင်ပြီးတော့ ဒီထက်ပိုပြီးတော့ security အကြောင်းကို ပြောကြမယ်ဆိုရင်တော့ CISSP လိုမျိုး certification တွေကို လေ့လာမှပဲ security ထဲမှာ သုံးတဲ့ အသုံးအနှုံးတွေနဲ့ security practice တွေကို သေချာသိရပါတော့တယ်။ သေချာတာတစ်ခုကတော့ security ဟာ နေရာတကာ မရှိမဖြစ်လိုအပ်တဲ့ အရာတစ်ခုဖြစ်လို့ နောက်ပိုင်းမှာ DevSecOps တို့ NetSecOps တို့ ဆိုပြီးတော့ အဆင်သင့် ရေနွေးနဲ့ ပြုတ်စားလို့ရတဲ့ instant noodle တွေလိုတောင် ဖြစ်လာကြပါပြီ။ နည်းပညာလောကကြီး အခုနောက်ပိုင်းမှာ အရမ်းကို demand ဖြစ်လွန်းပါတယ်။ တစ်ချိန်တစ်ခါက Network Specialist တို့ Linux System Specialist တို့ဆိုပြီးတော့ သီးသန့် specialist တွေက ကိုယ်သန်ရာသန်ရာမှာပဲ တစိုက်မတ်မတ် လေ့လာကျက်စားကြပြီးတော့မှ subject matter experts တွေရယ်လို့တောင်မှ ပူဇော်ပသရာ ဖြစ်ခဲ့ကြပါတယ်။ အခုများတော့ နည်းပညာလောကထဲကို စဝင်ချင်တယ်ဆိုရင် အကုန်လုံးသိထားရမယ်ဆိုပြီးတော့ ရှိသမျှ specialization တွေအကုန်လုံးကို role တစ်ခုအနေနဲ့ ဖန်တီးလာကြပါတယ်။ DevOps ရဲ့ culture ရေစီးကြောင်းကို သိရင်တော့ဖြင့် DevOps တို့ DevSecOps တို့ဆိုတာ job role တွေ job title တွေထက်စာရင် practice တစ်ခု၊ streamline တစ်ခုအနေနဲ့ မြင်တာကို ပိုပြီးတော့ သဘောကြပါတယ်။ သိသော်လည်း အခုအနောက်ပိုင်းမှာ company တွေက အလုပ်ခေါ်ပြီဆိုရင်ဖြင့် DevOps Engineer တို့ Site Reliability Engineer (SRE) တို့ဆိုပြီးတော့ entry level မှာတင်ကို တော်တော်လေးကို expect လုပ်ကြလွန်းလို့ ဘယ်ကနေစလိုက်ရမှန်းတောင် မသိတော့ပါဘူး။ DevOps ရဲ့ ရေစီးကြောင်းဟာ နည်းပညာသမိုင်းမှာ သေချာတော့ သိထားစရာတွေပါ။
ဒီတလောမှာ SELinux အကြောင်းတွေကို စိတ်ဝင်တစား လိုက်ရှာဖတ်ရာကနေပြီးတော့ SELinux ရဲ့ အတိမ်အနက်ကို အနည်းငယ်ရိမ်ဖမ်း သံဖမ်းမိလာပါတော့တယ်။ system တစ်ခုကို setup လုပ်ပြီဆိုရင်ဖြင့် စာရေးသူဟာ stable ဖြစ်ချင်တယ် ဆိုရင် CentOS ကို အမြဲတမ်းရွေးလေ့ရှိပါတယ်။ RHEL ရဲ့ ကောင်းမွေတွေကို အကုန်ရနိုင်တဲ့ အပြင် CentOS ရဲ့ release cadence ကတော်တော်လေးကို ငြိမ်လို့ အမြဲတမ်းလိုလို သူ့ကိုပဲ production မှာ သုံးဖို့အတွက် ရွေးသလို အခြားလူတွေအတွက်လည်း CentOS ကို recommend လုပ်ပါတယ်။ နည်းနည်း modernized ဖြစ်တဲ့ distro ကိုအသုံးပြုချင်ရင်တော့ Ubuntu LTS ကို သုံးပါတယ်။ ကိုယ်အသုံးပြုမယ့် အရာပေါ်မှာမူတည်ပြီးတော့ လိုအပ်ရင် လိုအပ်သလို အဆင်ပြေမယ်လို့ ထင်တဲ့ဟာကို သုံးဖြစ်ပါတယ်။ အဲ့ဒီအခါမှာ CentOS ကို အသုံးပြုပြီဆိုတာနဲ့ SELinux ဆိုတဲ့ security layer နောက်တစ်ခုထပ်တိုးလာလို့ တခါတလေပိုပြီးတော့ ကသီတယ်လို့ အရင်ထင်မိတာတော့ အမှန်ပါ။ အမှန်က SELinux ကို ကောင်းကောင်းသိထားနားလည်ထားရင်တော့ နည်းနည်းပိုကောင်းမယ်လို့ ထင်ပါတယ်။ အစပိုင်းမှာတော့ SELinux ဟာ ဘယ်လိုအလုပ်လုပ်သလဲဆိုတာ မသိတာတကြောင်းနဲ့ ဘယ်လိုမှန်အောင်လို့ configure လုပ်ရမလဲဆိုတာကို မသိတဲ့အတွက် permissive မှာပဲ ထားပြီးတော့ အလွယ်လုပ်လိုက်ခဲ့မိပါတယ်။ အချို့ forum တွေမှာလိုက်ပြီးတော့ ဟိုဖတ်ဒီဖတ်နဲ့ သဘောပေါက်လာတာကတော့ SELinux ကိုမှန်အောင် configure လုပ်နိုင်ရင် permissive မှာထားစရာမလိုပဲ ကိုယ်လိုချင်တဲ့အရာကို အလုပ်ဖြစ်အောင် setup လုပ်နိုင်တယ်ဆိုတာ သိလာပါတော့တယ်။ သေချာလိုက်ဖတ်ကြည့်တော့ ပုံမှန်ကိုယ်အသုံးပြုတဲ့ user permission တွေထက် ပိုတယ်ဆိုတာလည်း သဘောပေါက်လာပါတယ်။ ဒီလိုနဲ့ပဲ SELinux အကြောင်းရေးမယ်ဆိုပြီးတော့ နှပ်ထားတာ နည်းနည်းတောင်ကြာသွားပါပြီ။ အဲ့ဒီ အကြွေးတွေကို ဆပ်ဖို့အတွက် ဒီစာကို ရေးဖို့ တဖန်အားထုတ်ရပြန်ပါတယ်။
SELinux ဆိုသည်မှာ
SELinux ရဲ့ အရှည်ကတော့ Security-Enhanced Linux ဖြစ်ပြီး SELinux ကိုတော့ နာမည်ကျော် အမေရိကန်နိုင်ငံရဲ့ စုံစမ်းစစ်ဆေးရေးအဖွဲ့ တစ်ခုဖြစ်တဲ့ National Security Agency (NSA) က Linux kernel အတွက်ဆိုပြီးတော့ Linux Security Modules (LSM) ကို project တစ်ခုအနေနဲ့ စတင်ခဲ့ပါတယ်။ ၂၀၀၀ ခုနှစ်မှာတော့ SELinux ကို open source community အတွက်ဆိုပြီး ပေးလာရာကနေ ၂၀၀၃ခုနှစ်မှ Linux kernel 2.6.x ထဲမှာထည့်သွင်း အသုံးပြုဖို့အတွက် အဆင်သင့်ဖြစ်ပါတော့တယ်။ သူဟာ Linux kernel အဆင့်မှာ ထည့်ပေါင်းပြီးတော့ အလုပ်လုပ်တာဖြစ်တဲ့အတွက် access control နဲ့ဆိုင်တဲ့ security policies တွေအတွက် များစွာထိရောက်တဲ့ security architecture တစ်ခုဖြစ်ပါတယ်။
Linux ရဲ့ access control လို့ ဆိုတဲ့နေရာမှာ အကြမ်းဖျင်းအားဖြင့် Discretionary Access Control (DAC) နဲ့ Mandatory Access Control (MAC) ဆိုပြီးတော့ ရှိပါတယ်။ DAC ဆိုတာကတော့ ACLs လိုမျိုး object တစ်ခုရဲ့ attribute ပေါ်မှာမူတည်ပြီးတော့ subject တွေကို ထိုထိုသော object တွေက access လုပ်တဲ့ နေရာမှာ ဘယ်လို UID တွေ၊ SUID တွေကို အသုံးပြုပြီးတော့ permission တွေနဲ့ ဘယ်လောက်ထိပဲ access လုပ်လို့ ရမလဲဆိုတာကို သတ်မှတ်ပေးတဲ့ access control တစ်မျိုးပါ။ ရေပူရအားဖြင့်တော့ object တစ်ခုဟာ owner ရှိပြီးတော့ grant နဲ့ deny ဆိုတဲ့ permission တွေကိုပေးနိုင်ပါတယ်။ ဥပမာဆိုရရင်တော့ဖြင့် Linux နဲ့ Windows တွေမှာသုံးတဲ့ file systems တွေဟာ ACL ကိုအသုံးပြုပြီးတော့ မည်သို့မည်ပုံ file တွေ၊ folder တွေကို restrict လုပ်လို့ရသလဲဆိုတာကို သတ်မှတ်ကြပါတယ်။ ဒီနေရာမှာ object ဆိုတာကတော့ file system တစ်ခုရဲ့ file တွေ folder တွေဖြစ်ပြီးတော့၊ subject ဆိုတာက user နဲ့ group တွေဖြစ်ပါတယ်။ DAC ဟာသူ့ရဲ့ သဘောသဘာဝအရ MAC လောက်တော့ မလုံခြုံဘူးလို့ မှတ်ထားနိုင်ပါတယ်။ DAC မှာ system တစ်ခုရဲ့ administrator တစ်ယောက်ဟာ ရှိသမျှ object တွေကို လိုက်ပြီးတော့ ACL နဲ့ တစ်ခုချင်းစီ လိုက်လံသတ်မှတ်ပေးစရာမလိုပါ။ User တစ်ယောက်ဟာ သူ့ကိုယ်ပိုင် account တစ်ခုအောက်မှာ file တွေ၊ folder တွေ ဖန်တီးလိုက ဖန်တီးနိုင်ပြီးတော့ ၄င်း user သည် ထို object ရဲ့ owner ဖြစ်နေလေသတည်း။ Object တစ်ခုရဲ့ owner တစ်ယောက်အနေနဲ့ သူသတ်မှတ်ချင်တဲ့ attribute ကို ထို object အတွက် လိုသလို သတ်မှတ်ပေးလို့ ရ၏။ ဒါကိုကြည့်ခြင်းအားဖြင့် distributed management model တစ်ခုဖြစ်သည်ဟု ဆိုနိုင်သည်။ အကယ်လိုများ permission မှားပြီးပေးထားလျှင် ထိုအတိုင်းပင် system က ပေးထားတဲ့ အမှားတိုင်းပဲ object ကို access ပေးလုပ်နိုင်သည့်အတွက် လုံးဝယုံကြည် စိတ်ချနိုင်သော access control management model မဟုတ်ပေ။ ဒီအတွက် ဒီ model ကို Discretionary Access Control (DAC) လို့ခေါ်ဆိုခြင်းဖြစ်သည်။ ဒီနေရာမှာ discretionary အဓိပ္ပာယ်ကတော့ လိုမှအသုံးပြုနိုင်တယ်၊ သာမညဖြစ်တယ်လို့ ဆိုရမှာပဲဖြစ်ပါတယ်။
အခြားတဘက်မှာတော့ Mandatory Access Control (MAC) ဆိုတဲ့ model ရှိပါတယ်။ MAC မှာတော့ hierarchical လို့ခေါ်တဲ့ security level ပေါ်မှာမူတည်ပြီးတော့ အဆင့်ဆင့် လိုက်ပြီးတော့ သတ်မှတ်ပေးရတဲ့ ကြိုးနီစနစ် ဆန်ဆန် system တစ်ခုလုံးကို administrative privilege ရှိတဲ့ group နဲ့ သူ့ member တွေပဲ လိုက်ပြီးတော့ သတ်မှတ်ပေးနိုင်တဲ့ access control system တစ်ခုဖြစ်ပါတယ်။ MAC ကို အသုံးပြုခြင်းအားဖြင့် kernel အဆင့်မှာ application တစ်ခုရဲ့ malicious သို့မဟုတ် flaw ဖြစ်နေတဲ့ အစိတ်အပိုင်းတွေကို ချုပ်ကိုင်နိုင်စွမ်းရှိတဲ့ access control security architecture တစ်ခုပါ။ ဒီနေရာမှာတော့ subject နဲ့ object လို့ဆိုတဲ့ နေရာမှာ subject ဆိုတာကတော့ system တစ်ခုရဲ့ process သို့မဟုတ် thread ကို ဆိုလိုရင်းဖြစ်ပြီးတော့၊ object ဆိုတာကတော့ အဲ့ဒီ system တစ်ခုရဲ့ constructs တွေဖြစ်တဲ့ files တွေ၊ directories တွေ၊ TCP/UDP ports တွေ နဲ့ shared memory segments တွေအပြင် IO devices တွေပါ ပါဝင် နိုင်ပါတယ်။ ဒီတော့ constructs ဆိုရင် system တစ်ခုမှာ ရှိနိုင်တဲ့ target တွေအကုန်လုံးကို object လို့သတ်မှတ်နိုင်ပါတယ်။ Subject မှာကော၊ object မှာပါ သက်ဆိုင်ရာ security attribute တွေနဲ့ ချိတ်ဆက်နိုင်လို့ အရိုးအရှင်းဆုံးပြောရရင် labeling လုပ်တယ်လို့လည်း ဆိုကြပါတယ်။ MAC ဟာ system တစ်ခုရဲ့ kernel အဆင့်မှာ အလုပ်လုပ်တာဖြစ်တဲ့အတွက် ပိုပြီးတော့ strict ဖြစ်တယ်၊ secure ဖြစ်တယ်လို့ ဆိုနိုင်ပါတယ်။ သက်ဆိုင်ရာ security policies တွေ attribute တွေကို labeling လုပ်ဖို့ရာအတွက် administrative privilege ရှိဖို့တော့ လိုပါတယ်။ MAC model ကို SELinux မှာသုံးပါတယ်။ ဒီတော့ SELinux ရဲ့ security ကိုထိန်းချုပ်တဲ့ နေရာမှာ kernel မှာအလုပ်လုပ်တာဖြစ်ပြီးတော့ လိုအပ်တဲ့ အပြောင်းအလဲ လုပ်လိုတယ်ဆိုရင်တော့ sudo သို့မဟုတ် root လို privilege တွေရှိမှပဲ လုပ်လို့ ရနိုင်မှာဖြစ်ပါတယ်။ ပုံမှန် RHEL ကနေဆင်းသက်လာတဲ့ RPM based distribution တွေမှာ SELinux ကို security layer တစ်ခု အနေနဲ့ ထပ်ဆောင်းထည့်ထားပြီးတော့၊ DEB based မှာလည်း AppArmor ဆိုတဲ့ MAC model ကိုအသုံးပြုတဲ့ kernel အဆင့်မှာအလုပ်လုပ်တဲ့ security feature တစ်ခုရှိပါတယ်။ နောက်ပိုင်း အချိန်ရမှပဲ AppArmor အကြောင်းကို အသေးစိတ်ရေးပါ့မယ်။ အခုတော့ SELinux အကြောင်းကိုဆက်သွားလိုက်ရအောင်။
SELinux ရဲ့ ထူးခြားချက်ကတော့ NSA မှာစတင်ပေါက်ဖွားလာတဲ့အတွက် multilevel security (MLS) ဆိုတဲ့ feature တစ်ခုပါပဲ။ ဒီ MLS ဆိုတာကတော့ တော်တော်လေးကို အဆင့်မြင့်သွားပြီဖြစ်တဲ့ အမေရိကန် military နဲ့ အခြားအဆင့်မြင့် နိုင်ငံတွေမှာ အသုံးပြုတဲ့ အထူးပြုလုပ်ထားတဲ့ military systems တွေမှာ အသုံးပြုပါတယ်။ ၄င်းနည်းတူ DEB based distro တွေမှာလည်း MLS အတွက် MAC implementation ရှိသလို၊ Windows မှာလည်း Mandatory Integrity Control ဆိုတဲ့ ဟာတွေရှိပါတယ်။ မည်သို့ပင်ဖြစ်စေ ကိုယ်ဟာ InfoSec professional တစ်ယောက်မဟုတ်ရင် system တစ်ခုရဲ့ ဒီလို ထပ်ဆောင်း security layer တွေအကြောင်းကို သီးသန့်လေ့လာဖြစ်မယ်မထင်ပါဘူး။ သို့သော် ကိုယ့်အနေနဲ့ RPM based distro တွေကို အသုံးပြုပြီဆိုရင်တော့ SELinux နဲ့ ရှောင်လွှဲလို့ရနိုင်မှာမဟုတ်ပါ။ သို့သော်… SELinux ကို bypass လုပ်တဲ့အနေနဲ့ RHEL၊ CentOS လို distro တွေမှာ setenforce ကို permissive သို့မဟုတ် disable လုပ်လိုက်တတ်ကြပါတယ်။ ဒီ့အတွက် SELinux ရဲ့ ကောင်းမွန်လှတဲ့ security layer ရဲ့ အရသာကို မသိနိုင်တော့ပါဘူး။ စာရေးသူတို့ ဒီထက်ကောင်းအောင်၊ system တစ်ခုကို ဒီထက်ပိုပြီးတော့ လုံခြုံအောင်လို့ SELinux ကို ထည့်သွင်းအသုံးပြုသင့်ပါတယ်။ ဒီတော့ SELinux ရဲ့ basics လေးတွေကို နည်းနည်းလေး လေ့လာကြည့်ရအောင်။
SELinux ဘယ်လိုအလုပ်လုပ်သလဲ
SELinux ပါဝင်တဲ့ Linux distro တွေမှာ out-of-box default သတ်မှတ်ထားတဲ့ SELinux Policy Database နဲ့ သက်ဆိုင်ရာ labeling တွေရှိပါတယ်။ ပုံမှန် operation မှာ ကိုယ်က ဘာမှသွားပြောင်းစရာမလိုပဲ ဒီအတိုင်း အသုံးပြုရင်လည်း ရပါတယ်။ သို့သော် ကိုယ်က system level မှာ တစ်ခုခုအပြောင်းအလဲလုပ်ပြီဆိုရင်တော့ အောက် က process အတိုင်းသွားပါတယ်။
Subject တစ်ခုဖြစ်တဲ့ application process တစ်ခုဟာ object တစ်ခုဖြစ်တဲ့ file တစ်ခုခုကို access လုပ်ဖို့ကြိုးစားတဲ့နေရာမှာ kernel မှာပါတဲ့ policy enforcement server ဟာ access vector cache (AVC) ကို သွားပြီး စစ်ကြည့်ပါတယ်။ အဲ့ဒီ AVC ဟာ subject ရော object ရဲ့ permission အကုန်လုံးကို သိမ်းဆည်းထားတဲ့နေရာပါ။
ဒီနေရာမှာ လိုအပ်တဲ့ permission ကိုပေးဖို့အတွက် AVC မှာလုံလောက်တဲ့ အချက်အလက် တွေမရှိဘူးဆိုကြပါစို့။ ဒါဆိုရင်တော့ နောက်အဆင့်အနေနဲ့ SELinux security server ရဲ့ policy database ကိုသွားပြီးတော့ ထို application process နဲ့ သူ access လုပ်ဖို့ ကြိုးစားတဲ့ file နှစ်ခုရဲ့ security context ကို subject-object matrix မှာ ထပ်မံ့စစ်ဆေးရပြန်ပါတယ်။
အဲ့ဒီနောက်မှာတော့ permission ကို granted လုပ်သလား၊ denied လုပ်သလားဆိုတာကို သိပါပြီ။ အကယ်လို့များ access ကို denied လုပ်ခံရမယ်ဆိုရင်တော့ avc: denied ဆိုတဲ့ message အသေးစိတ်ကို /var/log/messages မှာသွားပြီးတော့ report လုပ်ပါတယ်။
SELinux ကို configure လုပ်ချင်တယ်ဆိုရင်တော့ /etc/sysconfig/selinux ဆိုတဲ့ configuration file မှာ သွားပြီးတော့ ကို်ယ်ထားချင်တဲ့ operating mode နဲ့ type ကို သတ်မှတ်ပေးလို့ရပါတယ်။ ဒီ /etc/sysconfig/selinux ဟာ အမှန်တကယ် SELinux ရဲ့ config ဖြစ်တဲ့ /etc/selinux/config ရဲ့ symbolic link ဖြစ်ပါတယ်။
CentOS သို့မဟုတ် Fedora လို RHEL ကဆင်းသက်လာတဲ့ distro တွေကိုသုံးတဲ့ အခါမှာ SELinux ရဲ့ operating mode ကို enforcing မှာ default အနေနဲ့ထားပါတယ်။ enforcing အပြင် အသုံးပြုလို့ရနိုင်တဲ့ အခြား mode တွေကတော့ permissive နဲ့ disabled ဆိုတဲ့ operating mode တွေပဲဖြစ်ပါတယ်။ Enforcing ဆိုတာကတော့ ရှင်းပါတယ် SELinux ကို သုံးကိုသုံးရမယ်လို့ enforce လုပ်ထားတာဖြစ်ပါတယ်။ Enforcing mode မှာ adminstrator ကသီးသန့် explicitly allow မလုပ်ထားတဲ့ အရာတွေ အားလုံးကို deny လုပ်ပြီးတော့ syslog မှာလည်း သွားပြီးတော့ report လုပ်ပါတယ်။ Permissive ဆိုတာကတော့ enforce မလုပ်တော့ပဲ denied ဖြစ်တဲ့ အရာတွေကို logging ပဲလုပ်ပြီးတော့ လိုက်ပြီးတော့ block မလုပ်ချင် denied မလုပ်ချင်ရင် ထားတဲ့ operating mode တစ်ခုဖြစ်ပါတယ်။ ဒီ permissive mode ကို troubleshooting လုပ်တဲ့အခါ relabeling လုပ်တဲ့အခါမျိုးမှာပဲ အသုံးပြုသင့်ပြီးတော့၊ system တစ်ခုရဲ့ normal daily operation မှာတော့ permissive ကိုမသုံးသင့်ပါဘူး။ နောက်ဆုံး operating mode ကတော့ disabled ဖြစ်ပါတယ်။ ဒီ mode မှာတော့ SELinux ကိုလုံးဝ disabled လုပ်လိုက်တာဖြစ်တဲ့ အတွက် permissive မှာလိုတောင် denied ဖြစ်တဲ့အရာတွေကို logging မလုပ်တော့ပါဘူး။ ဒီ disabled mode ကိုတော့ တိကျတဲ့ အကြောင်းအရင်း ခိုင်ခိုင်လုံလုံမရှိပဲနဲ့ လုံးဝ မထားသင့်ပါဘူး။ ဘာလို့လဲဆိုတော့ SELinux ဟာ disabled mode မှာထားလိုက်တာနဲ့ ရှိသမျှ security policies တွေအားလုံးမှာ label တွေအားလုံးကိုသွားဖြုတ်ပါတော့တယ်။ ဒါကြောင့် နောက်တခါ enforcing ဖြစ်ဖြစ်၊ permissive ဖြစ်ဖြစ် operating mode တစ်ခုပြန်ထားချင်ရင် system reboot လုပ်တဲ့အခါမှာ kernel ဟာ SELinux ရဲ့ရှိသမျှ security policies တွေကို labeling ပြန်လုပ်ရပါတယ်။ Label အားလုံးအတွက် database ကို ပြန်ပြီး build လုပ်ရတာဖြစ်တဲ့အတွက် အချိန်အားဖြင့် ကိုယ့် system တစ်ခုရဲ့ complexity ပေါ်မှာမူတည်ပြီးတော့ မိနစ် ၃၀ ကနေ ၁ နာရီကျော်လောက်ထိကြာတတ်ပါတယ်။ ဒါကြောင့် production မှာ သေချာတိကျတဲ့ အကြောင်းမရှိပဲနဲ့တော့ SELinux ကို လုံးဝ disabled မလုပ်သင့်ပါဘူး။ တခါတလေကျရင်တော့ SELinux နဲ့ ပတ်သတ်ပြီးတော့ troubleshoot စရာရှိရင်တော့လည်း disabled mode ကို အသုံးပြုနိုင်ပါတယ်။
SELinux ရဲ့ type အကြောင်းလည်း ဒီနေရာ အနည်းငယ် သိထားဖို့တော့လိုပါလိမ့်မယ်။ /etc/sysconfig/selinux ရဲ့ ဒုတိယ အပိုင်းမှာတော့ SELINUXTYPE ဆိုတာရှိပြန်ပါတယ်။ အဲ့ဒီမှာလည်း အသုံးပြုနိုင်တဲ့ option သုံးမျိုးရှိပြန်ပါတယ်။ ထိုသုံးခုကတော့ targeted၊ strict နဲ့ mls တို့ပဲဖြစ်ပါတယ်။ ဒီနေရာမှာတော့ SELinux ရဲ့ ကျန်တဲ့ configuration တွေကို ဘယ်မှာသွားပြီးတော့ ရှာကြည့်နိုင်သလဲဆိုတဲ့ directory path ကို သတ်မှတ်ပေးတဲ့ နေရာပဲဖြစ်ပါတယ်။ ထားပါတော့… ကိုယ်က default အတိုင်းလာတဲ့ type targeted ကို အသုံးပြုရင် SELinux ဟာ /etc/selinux/targeted ဆိုတဲ့ directory မှာသွားပြီးတော့ ကြည့်ပါတယ်။ ၄င်းနည်းတူ strict ကို သုံးရင် /etc/selinux/strict ကိုကြည့်ပြီးတော့၊ mls ကိုသုံးရင်တော့ /etc/selinux/mls ကိုသုံးပါတယ်။ ဒီလိုမှမဟုတ် ပဲကိုယ်က ကိုယ်ပိုင် policy ကို ရေးချင်တယ် ဆိုရင်တော့ ကိုယ်တိုင် directory တစ်ခုကို /etc/selinux/ အောက်မှာတည်ဆောက်ပြီးတော့ ကိုယ်ပိုင် policy နာမည်နဲ့ ထည့်သွင်း အသုံးပြုရင်လည်း ရပါတယ်။ ဆိုလိုရင်းက /etc/selinux/mypolicy လို့ တည်ဆောက်ပြီးတော့ SELINUXTYPE= mypolicy ကို အသုံးပြုချင်ရင် ဖြစ်နိုင်ပါတယ်။ ဒီလို ကိုယ်ပိုင် policy ကို အသုံးပြုရင်တော့ touch ./autorelabel လို ဆိုပြီးတော့ system ကို relabel လုပ်ဖို့အတွက် reboot လုပ်ပေးရပါ့မယ်။ နောက်ပြီးတော့ type ကို targeted သုံးမယ်ဆိုရင်တော့ system မှာပါဝင်တဲ့ သတ်မှတ်ထားတဲ့ protected daemons တွေအတွက်ပဲ အကြုံဝင်ပါတယ်။ ဒီ protected daemons တွေကိုလည်း RHEL ရဲ့ version တစ်ခုနဲ့ တစ်ခုစီမှာ မတူနိုင်တာမို့ အသေအချာတော့ မပြောတတ်ပါ။ အကြမ်းအားဖြင့်တော့ terminal မှာ getsebool -a ဆိုပြီးတော့ ရိုက်ထည့်ပြီးတော့ ကြည့်လိုက်ရင် seboolean ကို အသုံးပြုပြီးတော့ on/off လုပ်လို့ရတဲ့ protected daemon တွေနဲ့ သက်ဆိုင်ရင် policy macro တွေကိုတွေ့နိုင် မှာပဲဖြစ်ပါတယ်။ Strict ကို SELINUXTYPE မှာသုံးမယ်ဆိုရင်တော့ system တစ်ခုလုံးကို full SELinux protection ရနိုင်မှာဖြစ်တဲ့အတွက် daemons တွေအားလုံး အတွက် အကြုံဝင်ပါတယ်။ SELINUXTYPE=mls ကို NSA နဲ့ အခြားသော အဆင့်မြင့်လုံခြုံရေး စနစ်မရှိမဖြစ်လိုအပ်တဲ့ government နဲ့ military တွေမှာအသုံးပြုပါတယ်။
SELinux အကြောင်းကို ဒီ post မှာ မိတ်ဆက်သဘောမျိုးနဲ့ မိတ်ဆက်ပေးချင်တဲ့ ဆန္ဒကြောင့်ရေးဖြစ်တာကြောင့် သူ့ရဲ့ အသေးစိတ်ကို ဖြန့်ကားပြီးတော့ ရေးချင်သော်လည်း မရေးတော့ပါ။ နောက်မှပဲ အေးအေးဆေးဆေး SELinux ကိုလက်တွေ့မှာ ဘယ်လို အသုံးပြုသလဲဆိုတာ ဥပမာနဲ့တကွရေးသွားပါ့မယ်။ ဒီတစ်ခုမှာတော့ post ကနည်းနည်းလည်း ရှည်နေပြီဖြစ်လို့ ဒီမှာပဲရပ်လိုက်ပါတော့မယ်။ SELinux ဆိုတာဘာလည်းဆိုတာတော့ အနည်းအကျဉ်း လေ့လာမိမယ်လို့တော့ မျှော်လင့်ရင်း အဆုံးသတ်လေသတည်း။
Last updated
