ການແກ້ໄຂບັນຫາທີ່ກ່ຽວຂ້ອງກັບ SELinux
ຖ້າທ່ານວາງແຜນທີ່ຈະເປີດໃຊ້ SELinux ໃນລະບົບທີ່ເຄີຍຖືກປິດໄວ້ກ່ອນໜ້ານີ້ ຫຼື ຖ້າທ່ານໃຊ້ບໍລິການໃນການກຳນົດຄ່າທີ່ບໍ່ແມ່ນມາດຕະຖານ, ທ່ານອາດຈະຕ້ອງແກ້ໄຂບັນຫາໃນສະຖານະການທີ່ອາດຈະຖືກບລັອກໂດຍ SELinux. ໝາຍເຫດວ່າໃນກໍລະນີສ່ວນໃຫຍ່, ການປະຕິເສດຈາກ SELinux ແມ່ນສັນຍານຂອງການກຳນົດຄ່າທີ່ຜິດພາດ.
ການລະບຸການປະຕິເສດຂອງ SELinux
ປະຕິບັດຕາມຂັ້ນຕອນທີ່ຈຳເປັນເທົ່ານັ້ນ; ໃນກໍລະນີສ່ວນໃຫຍ່, ທ່ານພຽງແຕ່ຕ້ອງເຮັດຂັ້ນຕອນທີ 1.
ຂັ້ນຕອນການປະຕິບັດ
-
ເມື່ອສະຖານະການຂອງທ່ານຖືກບລັອກໂດຍ SELinux, ໄຟລ໌
/var/log/audit/audit.logແມ່ນບ່ອນທຳອິດທີ່ຈະກວດສອບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການປະຕິເສດ. ເພື່ອສອບຖາມ Audit logs, ໃຫ້ໃຊ້ເຄື່ອງມືausearch. ເນື່ອງຈາກການຕັດສິນໃຈຂອງ SELinux ເຊັ່ນ: ການອະນຸຍາດ ຫຼື ບໍ່ອະນຸຍາດໃຫ້ເຂົ້າເຖິງ ແມ່ນຖືກເກັບໄວ້ໃນ cache ແລະ cache ນີ້ເອີ້ນວ່າ Access Vector Cache (AVC), ໃຫ້ໃຊ້ຄ່າAVCແລະUSER_AVCສຳລັບພາລາມິເຕີປະເພດຂໍ້ຄວາມ, ຕົວຢ່າງ:$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recentຖ້າບໍ່ມີຂໍ້ມູນທີ່ກົງກັນ, ໃຫ້ກວດສອບວ່າ Audit daemon ກຳລັງເຮັດວຽກຢູ່ຫຼືບໍ່. ຖ້າບໍ່, ໃຫ້ເຮັດຊ້ຳສະຖານະການທີ່ຖືກປະຕິເສດຫຼັງຈາກທີ່ທ່ານເລີ່ມ auditd ແລະ ກວດສອບ Audit log ອີກຄັ້ງ.
-
ໃນກໍລະນີທີ່ auditd ກຳລັງເຮັດວຽກຢູ່, ແຕ່ບໍ່ມີຂໍ້ມູນທີ່ກົງກັນໃນຜົນຂອງ ausearch, ໃຫ້ກວດສອບຂໍ້ຄວາມທີ່ສະໜອງໂດຍ systemd Journal:
$ sudo journalctl -t setroubleshoot -
ຖ້າ SELinux ເປີດໃຊ້ງານຢູ່ ແລະ Audit daemon ບໍ່ໄດ້ເຮັດວຽກໃນລະບົບຂອງທ່ານ, ໃຫ້ຄົ້ນຫາຂໍ້ຄວາມ SELinux ບາງຢ່າງໃນຜົນຂອງຄຳສັ່ງ dmesg:
$ sudo dmesg | grep -i -e type=1300 -e type=1400 -
ເຖິງແມ່ນວ່າຈະມີການກວດສອບສາມຢ່າງຂ້າງເທິງແລ້ວ, ກໍຍັງເປັນໄປໄດ້ວ່າທ່ານອາດຈະບໍ່ພົບຫຍັງເລີຍ. ໃນກໍລະນີນີ້, ການປະຕິເສດຈາກ AVC ອາດຈະຖືກປິດສຽງໄວ້ເນື່ອງຈາກກົດ
dontaudit.ເພື່ອປິດໃຊ້ງານກົດ
dontauditຊົ່ວຄາວ, ເພື່ອອະນຸຍາດໃຫ້ບັນທຶກການປະຕິເສດທັງໝົດ:$ sudo semodule -DBຫຼັງຈາກທີ່ທ່ານລອງສະຖານະການທີ່ຖືກປະຕິເສດຄືນໃໝ່ ແລະ ພົບຂໍ້ຄວາມການປະຕິເສດໂດຍໃຊ້ຂັ້ນຕອນກ່ອນໜ້ານີ້, ຄຳສັ່ງຕໍ່ໄປນີ້ຈະເປີດໃຊ້ງານກົດ
dontauditໃນນະໂຍບາຍອີກຄັ້ງ:$ sudo semodule -B -
ຖ້າທ່ານໄດ້ປະຕິບັດຕາມທັງສີ່ຂັ້ນຕອນກ່ອນໜ້ານີ້ແລ້ວ ແລະ ບັນຫາຍັງບໍ່ຖືກລະບຸ, ໃຫ້ພິຈາລະນາເບິ່ງວ່າ SELinux ໄດ້ບລັອກສະຖານະການຂອງທ່ານແທ້ຫຼືບໍ່:
-
ປ່ຽນເປັນໂໝດ permissive:
$ sudo setenforce 0 $ getenforce Permissive -
ເຮັດຊ້ຳສະຖານະການຂອງທ່ານ.
-
ຖ້າບັນຫາຍັງເກີດຂຶ້ນຢູ່, ສະແດງວ່າສິ່ງອື່ນທີ່ບໍ່ແມ່ນ SELinux ກຳລັງບລັອກສະຖານະການຂອງທ່ານ.
ການວິເຄາະຂໍ້ຄວາມການປະຕິເສດຂອງ SELinux
ຫຼັງຈາກລະບຸໄດ້ວ່າ SELinux ກຳລັງບລັອກສະຖານະການຂອງທ່ານ, ທ່ານອາດຈະຕ້ອງວິເຄາະສາເຫດຕົ້ນຕໍກ່ອນທີ່ຈະເລືອກວິທີແກ້ໄຂ.
ສິ່ງທີ່ຕ້ອງມີກ່ອນ
-
ແພັກເກດ
policycoreutils-python-utilsແລະsetroubleshoot-serverຖືກຕິດຕັ້ງຢູ່ໃນລະບົບຂອງທ່ານແລ້ວ.
ຂັ້ນຕອນການປະຕິບັດ
-
ສະແດງລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການປະຕິເສດທີ່ຖືກບັນທຶກໄວ້ໂດຍໃຊ້ຄຳສັ່ງ
sealert, ຕົວຢ່າງ:$ sealert -l "*" SELinux is preventing /usr/bin/passwd from write access on the file /root/test. ***** Plugin leaks (86.2 confidence) suggests ***************************** ຖ້າທ່ານຕ້ອງການບໍ່ສົນໃຈ passwd ທີ່ພະຍາຍາມຂຽນໄຟລ໌ທົດສອບ, ເພາະທ່ານເຊື່ອວ່າມັນບໍ່ຄວນຈະຕ້ອງມີສິດເຂົ້າເຖິງນີ້. ຈາກນັ້ນທ່ານຄວນລາຍງານວ່າມັນເປັນ bug. ທ່ານສາມາດສ້າງໂມດູນນະໂຍບາຍທ້ອງຖິ່ນເພື່ອ dontaudit ການເຂົ້າເຖິງນີ້. ໃຫ້ປະຕິບັດ: # ausearch -x /usr/bin/passwd --raw | audit2allow -D -M my-passwd # semodule -X 300 -i my-passwd.pp ***** Plugin catchall (14.7 confidence) suggests ************************** ... Raw Audit Messages type=AVC msg=audit(1553609555.619:127): avc: denied { write } for pid=4097 comm="passwd" path="/root/test" dev="dm-0" ino=17142697 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0 .. Hash: passwd,passwd_t,admin_home_t,file,write -
ຖ້າຜົນທີ່ໄດ້ຮັບໃນຂັ້ນຕອນກ່ອນໜ້ານີ້ບໍ່ມີຄຳແນະນຳທີ່ຊັດເຈນ:
-
ເປີດໃຊ້ການກວດສອບເສັ້ນທາງເຕັມ (full-path auditing) ເພື່ອເບິ່ງເສັ້ນທາງເຕັມຂອງວັດຖຸທີ່ຖືກເຂົ້າເຖິງ ແລະ ເຮັດໃຫ້ເຫັນຟິລເຫດການ Linux Audit ເພີ່ມເຕີມ:
$ sudo auditctl -w /etc/shadow -p w -k shadow-write -
ລຶບ
setroubleshootcache:$ sudo rm -f /var/lib/setroubleshoot/setroubleshoot.xml -
ເຮັດໃຫ້ບັນຫາເກີດຂຶ້ນຊ້ຳອີກຄັ້ງ.
-
ເຮັດຊ້ຳຂັ້ນຕອນທີ 1.
ຫຼັງຈາກສິ້ນສຸດຂັ້ນຕອນ, ໃຫ້ປິດການກວດສອບເສັ້ນທາງເຕັມ:
$ sudo auditctl -W /etc/shadow -p w -k shadow-write
-
-
ຖ້າ
sealertສົ່ງຄືນພຽງແຕ່ຄຳແນະນຳແບບcatchallຫຼື ແນະນຳໃຫ້ເພີ່ມກົດໃໝ່ໂດຍໃຊ້ເຄື່ອງມືaudit2allow, ໃຫ້ປຽບທຽບບັນຫາຂອງທ່ານກັບຕົວຢ່າງທີ່ລະບຸ ແລະ ອະທິບາຍໄວ້ໃນ SELinux denials in the Audit log.
ແຫຼ່ງຂໍ້ມູນເພີ່ມເຕີມ
-
ໜ້າ man page ຂອງ
sealert(8)
ການແກ້ໄຂການປະຕິເສດຂອງ SELinux ທີ່ໄດ້ວິເຄາະແລ້ວ
ໃນກໍລະນີສ່ວນໃຫຍ່, ຄຳແນະນຳທີ່ສະໜອງໂດຍເຄື່ອງມື sealert ຈະໃຫ້ທິດທາງທີ່ຖືກຕ້ອງກ່ຽວກັບວິທີແກ້ໄຂບັນຫາທີ່ກ່ຽວຂ້ອງກັບນະໂຍບາຍ SELinux. ເບິ່ງ Analyzing SELinux denial messages ສຳລັບຂໍ້ມູນກ່ຽວກັບວິທີໃຊ້ sealert ເພື່ອວິເຄາະການປະຕິເສດຂອງ SELinux.
ຄວນລະມັດລະວັງເມື່ອເຄື່ອງມືແນະນຳໃຫ້ໃຊ້ audit2allow ສຳລັບການປ່ຽນແປງການກຳນົດຄ່າ. ທ່ານບໍ່ຄວນໃຊ້ audit2allow ເພື່ອສ້າງໂມດູນນະໂຍບາຍທ້ອງຖິ່ນເປັນທາງເລືອກທຳອິດເມື່ອທ່ານເຫັນການປະຕິເສດຈາກ SELinux. ການແກ້ໄຂບັນຫາຄວນເລີ່ມຕົ້ນດ້ວຍການກວດສອບວ່າມີບັນຫາເລື່ອງການຕິດປ້າຍ (labeling) ຫຼື ບໍ່. ກໍລະນີທີ່ພົບເລື້ອຍທີ່ສຸດອັນດັບສອງແມ່ນທ່ານໄດ້ປ່ຽນແປງການກຳນົດຄ່າຂອງ process, ແລ້ວທ່ານລືມບອກ SELinux ກ່ຽວກັບເລື່ອງນັ້ນ.
ບັນຫາການຕິດປ້າຍ (Labeling)
ສາເຫດທົ່ວໄປຂອງບັນຫາການຕິດປ້າຍແມ່ນເມື່ອມີການໃຊ້ໄດເຣັກທໍຣີທີ່ບໍ່ແມ່ນມາດຕະຖານສຳລັບບໍລິການໃດໜຶ່ງ. ຕົວຢ່າງ: ແທນທີ່ຈະໃຊ້ /var/www/html/ ສຳລັບເວັບໄຊ, ຜູ້ດູແລລະບົບອາດຈະຕ້ອງການໃຊ້ /srv/myweb/. ໃນ Red Hat Enterprise Linux, ໄດເຣັກທໍຣີ /srv ຈະຖືກຕິດປ້າຍດ້ວຍປະເພດ var_t. ໄຟລ໌ ແລະ ໄດເຣັກທໍຣີທີ່ຖືກສ້າງຂຶ້ນໃນ /srv ຈະສືບທອດປະເພດນີ້. ນອກຈາກນີ້, ວັດຖຸທີ່ຖືກສ້າງຂຶ້ນໃໝ່ໃນໄດເຣັກທໍຣີລະດັບສູງສຸດ ເຊັ່ນ /myserver, ສາມາດຖືກຕິດປ້າຍດ້ວຍປະເພດ default_t. SELinux ຈະປ້ອງກັນບໍ່ໃຫ້ Apache HTTP Server (httpd) ເຂົ້າເຖິງປະເພດເຫຼົ່ານີ້ທັງສອງ. ເພື່ອອະນຸຍາດໃຫ້ເຂົ້າເຖິງ, SELinux ຕ້ອງຮູ້ວ່າໄຟລ໌ໃນ /srv/myweb/ ນັ້ນແມ່ນໃຫ້ httpd ສາມາດເຂົ້າເຖິງໄດ້:
$ sudo semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"
ຄຳສັ່ງ semanage ນີ້ຈະເພີ່ມບໍລິບົດ (context) ສຳລັບໄດເຣັກທໍຣີ /srv/myweb/ ແລະ ໄຟລ໌ກັບໄດເຣັກທໍຣີທັງໝົດທີ່ຢູ່ພາຍໃຕ້ມັນເຂົ້າໃນການກຳນົດຄ່າ file-context ຂອງ SELinux. ເຄື່ອງມື semanage ຈະບໍ່ປ່ຽນແປງ context ໂດຍກົງ. ໃນຖານະ root, ໃຫ້ໃຊ້ເຄື່ອງມື restorecon ເພື່ອນຳໃຊ້ການປ່ຽນແປງ:
$ sudo restorecon -R -v /srv/myweb
ບໍລິບົດ (Context) ບໍ່ຖືກຕ້ອງ
ເຄື່ອງມື matchpathcon ຈະກວດສອບ context ຂອງເສັ້ນທາງໄຟລ໌ ແລະ ປຽບທຽບມັນກັບປ້າຍມາດຕະຖານສຳລັບເສັ້ນທາງນັ້ນ. ຕົວຢ່າງຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນການໃຊ້ matchpathcon ກັບໄດເຣັກທໍຣີທີ່ມີໄຟລ໌ທີ່ຖືກຕິດປ້າຍບໍ່ຖືກຕ້ອງ:
$ matchpathcon -V /var/www/html/*
/var/www/html/index.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/page1.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
ໃນຕົວຢ່າງນີ້, ໄຟລ໌ index.html ແລະ page1.html ຖືກຕິດປ້າຍດ້ວຍປະເພດ user_home_t. ປະເພດນີ້ແມ່ນໃຊ້ສຳລັບໄຟລ໌ໃນໄດເຣັກທໍຣີ home ຂອງຜູ້ໃຊ້. ການໃຊ້ຄຳສັ່ງ mv ເພື່ອຍ້າຍໄຟລ໌ຈາກໄດເຣັກທໍຣີ home ຂອງທ່ານອາດສົ່ງຜົນໃຫ້ໄຟລ໌ຖືກຕິດປ້າຍດ້ວຍປະເພດ user_home_t. ປະເພດນີ້ບໍ່ຄວນມີຢູ່ນອກໄດເຣັກທໍຣີ home. ໃຫ້ໃຊ້ເຄື່ອງມື restorecon ເພື່ອຄືນຄ່າໄຟລ໌ເຫຼົ່ານັ້ນໃຫ້ເປັນປະເພດທີ່ຖືກຕ້ອງ:
$ sudo restorecon -v /var/www/html/index.html
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0
ເພື່ອຄືນຄ່າ context ສຳລັບໄຟລ໌ທັງໝົດພາຍໃຕ້ໄດເຣັກທໍຣີ, ໃຫ້ໃຊ້ຕົວເລືອກ -R:
$ sudo restorecon -R -v /var/www/html/
restorecon reset /var/www/html/page1.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
ແອັບພລິເຄຊັນທີ່ຖືກຄວບຄຸມ (Confined) ຖືກກຳນົດຄ່າໃນຮູບແບບທີ່ບໍ່ແມ່ນມາດຕະຖານ
ບໍລິການສາມາດເຮັດວຽກໄດ້ໃນຫຼາຍຮູບແບບ. ເພື່ອໃຫ້ກວມເອົາເລື່ອງນັ້ນ, ທ່ານຈຳເປັນຕ້ອງລະບຸວ່າທ່ານເປີດໃຊ້ບໍລິການຂອງທ່ານແນວໃດ. ທ່ານສາມາດເຮັດສິ່ງນີ້ໄດ້ຜ່ານ SELinux booleans ທີ່ອະນຸຍາດໃຫ້ປ່ຽນແປງບາງສ່ວນຂອງນະໂຍບາຍ SELinux ໃນຂະນະທີ່ລະບົບກຳລັງເຮັດວຽກ. ນີ້ຊ່ວຍໃຫ້ສາມາດປ່ຽນແປງໄດ້ ເຊັ່ນ: ການອະນຸຍາດໃຫ້ບໍລິການເຂົ້າເຖິງ NFS volumes ໂດຍບໍ່ຕ້ອງໂຫຼດ ຫຼື compile ນະໂຍບາຍ SELinux ໃໝ່. ນອກຈາກນີ້, ການເປີດໃຊ້ບໍລິການໃນໝາຍເລກພອດທີ່ບໍ່ແມ່ນຄ່າເລີ່ມຕົ້ນ ຮຽກຮ້ອງໃຫ້ມີການອັບເດດການກຳນົດຄ່ານະໂຍບາຍໂດຍໃຊ້ຄຳສັ່ງ semanage.
ຕົວຢ່າງ: ເພື່ອອະນຸຍາດໃຫ້ Apache HTTP Server ສື່ສານກັບ MariaDB, ໃຫ້ເປີດໃຊ້ boolean httpd_can_network_connect_db:
$ sudo setsebool -P httpd_can_network_connect_db on
ໝາຍເຫດວ່າຕົວເລືອກ -P ຈະເຮັດໃຫ້ການຕັ້ງຄ່ານີ້ຄົງຢູ່ເຖິງແມ່ນວ່າຈະມີການ reboot ລະບົບກໍຕາມ.
ຖ້າການເຂົ້າເຖິງຖືກປະຕິເສດສຳລັບບໍລິການໃດໜຶ່ງ, ໃຫ້ໃຊ້ເຄື່ອງມື getsebool ແລະ grep ເພື່ອເບິ່ງວ່າມີ boolean ໃດແດ່ທີ່ສາມາດໃຊ້ເພື່ອອະນຸຍາດໃຫ້ເຂົ້າເຖິງໄດ້. ຕົວຢ່າງ: ໃຊ້ຄຳສັ່ງ getsebool -a | grep ftp ເພື່ອຄົ້ນຫາ boolean ທີ່ກ່ຽວຂ້ອງກັບ FTP:
$ getsebool -a | grep ftp
ftpd_anon_write --> off
ftpd_full_access --> off
ftpd_use_cifs --> off
ftpd_use_nfs --> off
ftpd_connect_db --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> off
ເພື່ອເອົາລາຍຊື່ຂອງ booleans ແລະ ກວດສອບວ່າພວກມັນຖືກເປີດ ຫຼື ປິດໃຊ້ງານຢູ່, ໃຫ້ໃຊ້ຄຳສັ່ງ getsebool -a. ເພື່ອເອົາລາຍຊື່ booleans ລວມທັງຄວາມໝາຍຂອງພວກມັນ, ໃຫ້ຕິດຕັ້ງແພັກເກດ selinux-policy-devel ແລະ ໃຊ້ຄຳສັ່ງ semanage boolean -l ໃນຖານະ root.
ໝາຍເລກພອດ (Port numbers)
ຂຶ້ນຢູ່ກັບການກຳນົດຄ່ານະໂຍບາຍ, ບໍລິການຕ່າງໆສາມາດຖືກອະນຸຍາດໃຫ້ເຮັດວຽກໄດ້ສະເພາະບາງໝາຍເລກພອດເທົ່ານັ້ນ. ການພະຍາຍາມປ່ຽນພອດທີ່ບໍລິການເຮັດວຽກໂດຍບໍ່ໄດ້ປ່ຽນແປງນະໂຍບາຍອາດສົ່ງຜົນໃຫ້ບໍລິການນັ້ນບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້. ຕົວຢ່າງ: ໃຫ້ໃຊ້ຄຳສັ່ງ semanage port -l | grep http ໃນຖານະ root ເພື່ອສະແດງລາຍຊື່ພອດທີ່ກ່ຽວຂ້ອງກັບ http:
$ sudo semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989
ປະເພດພອດ http_port_t ກຳນົດພອດທີ່ Apache HTTP Server ສາມາດ listen ໄດ້, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນພອດ TCP 80, 443, 488, 8008, 8009, ແລະ 8443. ຖ້າຜູ້ດູແລລະບົບກຳນົດຄ່າ httpd.conf ໃຫ້ httpd listen ໃນພອດ 9876 (Listen 9876), ແຕ່ບໍ່ໄດ້ອັບເດດນະໂຍບາຍໃຫ້ກົງກັນ, ຄຳສັ່ງຕໍ່ໄປນີ້ຈະລົ້ມເຫຼວ:
$ sudo systemctl start httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
$ sudo systemctl status httpd.service
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
Active: failed (Result: exit-code) since Thu 2013-08-15 09:57:05 CEST; 59s ago
Process: 16874 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=0/SUCCESS)
Process: 16870 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
ຂໍ້ຄວາມການປະຕິເສດຂອງ SELinux ທີ່ຄ້າຍຄືກັບຕໍ່ໄປນີ້ຈະຖືກບັນທຶກໄວ້ໃນ /var/log/audit/audit.log:
type=AVC msg=audit(1225948455.061:294): avc: denied { name_bind } for pid=4997 comm="httpd" src=9876 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
ເພື່ອອະນຸຍາດໃຫ້ httpd listen ໃນພອດທີ່ບໍ່ໄດ້ລະບຸໄວ້ສຳລັບປະເພດພອດ http_port_t, ໃຫ້ໃຊ້ຄຳສັ່ງ semanage port ເພື່ອກຳນົດປ້າຍ (label) ອື່ນໃຫ້ກັບພອດນັ້ນ:
$ sudo semanage port -a -t http_port_t -p tcp 9876
ຕົວເລືອກ -a ຈະເພີ່ມບັນທຶກໃໝ່; ຕົວເລືອກ -t ກຳນົດປະເພດ; ແລະ ຕົວເລືອກ -p ກຳນົດໂປຣໂຕຄໍ. ອາຄິວເມນສຸດທ້າຍແມ່ນໝາຍເລກພອດທີ່ຈະເພີ່ມ.
ກໍລະນີພິເສດ, ແອັບພລິເຄຊັນທີ່ກຳລັງພັດທະນາ ຫຼື ເພພັງ, ແລະ ລະບົບທີ່ຖືກບຸກລຸກ
ແອັບພລິເຄຊັນອາດຈະມີ bug, ເຊິ່ງສົ່ງຜົນໃຫ້ SELinux ປະຕິເສດການເຂົ້າເຖິງ. ນອກຈາກນີ້, ກົດຂອງ SELinux ກໍມີການພັດທະນາຢູ່ສະເໝີ – SELinux ອາດຈະບໍ່ເຄີຍເຫັນແອັບພລິເຄຊັນທີ່ເຮັດວຽກໃນຮູບແບບໃດໜຶ່ງມາກ່ອນ, ເຮັດໃຫ້ມັນປະຕິເສດການເຂົ້າເຖິງ ເຖິງແມ່ນວ່າແອັບພລິເຄຊັນຈະເຮັດວຽກຕາມທີ່ຄາດໄວ້ກໍຕາມ. ຕົວຢ່າງ: ຖ້າມີ PostgreSQL ເວີຊັນໃໝ່ຖືກປ່ອຍອອກມາ, ມັນອາດຈະເຮັດບາງຢ່າງທີ່ນະໂຍບາຍປັດຈຸບັນຍັງບໍ່ທັນກວມເອົາ, ເຮັດໃຫ້ການເຂົ້າເຖິງຖືກປະຕິເສດ ເຖິງແມ່ນວ່າມັນຄວນຈະໄດ້ຮັບການອະນຸຍາດກໍຕາມ.
ສຳລັບສະຖານະການເຫຼົ່ານີ້, ຫຼັງຈາກການເຂົ້າເຖິງຖືກປະຕິເສດ, ໃຫ້ໃຊ້ເຄື່ອງມື audit2allow ເພື່ອສ້າງໂມດູນນະໂຍບາຍກຳນົດເອງເພື່ອອະນຸຍາດການເຂົ້າເຖິງ. ທ່ານສາມາດລາຍງານກົດທີ່ຫາຍໄປໃນນະໂຍບາຍ SELinux ໄດ້ທີ່ Red Hat Bugzilla. ສຳລັບ Red Hat Enterprise Linux 8, ໃຫ້ສ້າງ bug ສຳລັບຜະລິດຕະພັນ Red Hat Enterprise Linux 8 ແລະ ເລືອກອົງປະກອບ selinux-policy. ໃຫ້ແນບຜົນຂອງຄຳສັ່ງ audit2allow -w -a ແລະ audit2allow -a ລົງໃນລາຍງານ bug ດັ່ງກ່າວ.
ຖ້າແອັບພລິເຄຊັນຮ້ອງຂໍສິດທິຄວາມປອດໄພລະດັບສູງ, ມັນອາດຈະເປັນສັນຍານວ່າແອັບພລິເຄຊັນນັ້ນຖືກບຸກລຸກ. ໃຫ້ໃຊ້ເຄື່ອງມືກວດຈັບການບຸກລຸກເພື່ອສຳຫຼວດພຶດຕິກຳທີ່ໜ້າສົງໄສດັ່ງກ່າວ.
Solution Engine ໃນ Red Hat Customer Portal ຍັງສາມາດໃຫ້ຄຳແນະນຳໃນຮູບແບບຂອງບົດຄວາມທີ່ມີວິທີແກ້ໄຂສຳລັບບັນຫາດຽວກັນ ຫຼື ບັນຫາທີ່ຄ້າຍຄືກັນທີ່ທ່ານກຳລັງປະສົບຢູ່. ໃຫ້ເລືອກຜະລິດຕະພັນ ແລະ ເວີຊັນທີ່ກ່ຽວຂ້ອງ ແລະ ໃຊ້ຄຳສຳຄັນທີ່ກ່ຽວກັບ SELinux ເຊັ່ນ selinux ຫຼື avc, ຮ່ວມກັບຊື່ບໍລິການ ຫຼື ແອັບພລິເຄຊັນທີ່ຖືກບລັອກ, ຕົວຢ່າງ: selinux samba.
ການປະຕິເສດຂອງ SELinux ໃນ audit log
ລະບົບ Linux Audit ຈະເກັບບັນທຶກເຫດການໄວ້ໃນໄຟລ໌ /var/log/audit/audit.log ໂດຍຄ່າເລີ່ມຕົ້ນ.
ເພື່ອສະແດງສະເພາະບັນທຶກທີ່ກ່ຽວຂ້ອງກັບ SELinux, ໃຫ້ໃຊ້ຄຳສັ່ງ ausearch ໂດຍກຳນົດພາລາມິເຕີປະເພດຂໍ້ຄວາມເປັນ AVC ແລະ AVC_USER ເປັນຢ່າງໜ້ອຍ, ຕົວຢ່າງ:
$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR
ລາຍການການປະຕິເສດຂອງ SELinux ໃນໄຟລ໌ Audit log ສາມາດມີລັກສະນະດັ່ງນີ້:
type=AVC msg=audit(1395177286.929:1638): avc: denied { read } for pid=6591 comm="httpd" name="webpages" dev="0:37" ino=2112 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
ສ່ວນທີ່ສຳຄັນທີ່ສຸດຂອງລາຍການນີ້ແມ່ນ:
-
avc: denied- ການກະທຳທີ່ປະຕິບັດໂດຍ SELinux ແລະ ຖືກບັນທຶກໄວ້ໃນ Access Vector Cache (AVC) -
{ read }- ການກະທຳທີ່ຖືກປະຕິເສດ -
pid=6591- ໝາຍເລກລະບຸ process ຂອງ subject ທີ່ພະຍາຍາມປະຕິບັດການກະທຳທີ່ຖືກປະຕິເສດ -
comm="httpd"- ຊື່ຂອງຄຳສັ່ງທີ່ຖືກໃຊ້ເພື່ອເອີ້ນ process ທີ່ຖືກວິເຄາະ -
httpd_t- ປະເພດ SELinux ຂອງ process -
nfs_t- ປະເພດ SELinux ຂອງວັດຖຸທີ່ໄດ້ຮັບຜົນກະທົບຈາກການກະທຳຂອງ process -
tclass=dir- ຄລາດຂອງວັດຖຸເປົ້າໝາຍ
ລາຍການ log ກ່ອນໜ້ານີ້ສາມາດແປໄດ້ວ່າ:
SELinux ໄດ້ປະຕິເສດ process httpd ທີ່ມີ PID 6591 ແລະ ປະເພດ httpd_t ບໍ່ໃຫ້ອ່ານຈາກໄດເຣັກທໍຣີທີ່ມີປະເພດ nfs_t.
ຂໍ້ຄວາມການປະຕິເສດຂອງ SELinux ຕໍ່ໄປນີ້ຈະເກີດຂຶ້ນເມື່ອ Apache HTTP Server ພະຍາຍາມເຂົ້າເຖິງໄດເຣັກທໍຣີທີ່ຖືກຕິດປ້າຍດ້ວຍປະເພດສຳລັບ Samba suite:
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
-
{ getattr }- ລາຍການgetattrລະບຸວ່າ process ຕົ້ນທາງກຳລັງພະຍາຍາມອ່ານຂໍ້ມູນສະຖານະຂອງໄຟລ໌ເປົ້າໝາຍ. ສິ່ງນີ້ເກີດຂຶ້ນກ່ອນການອ່ານໄຟລ໌. SELinux ປະຕິເສດການກະທຳນີ້ເພາະ process ເຂົ້າເຖິງໄຟລ໌ທີ່ບໍ່ມີປ້າຍ (label) ທີ່ເໝາະສົມ. ສິດການເຂົ້າເຖິງທີ່ພົບເລື້ອຍໄດ້ແກ່getattr,read, ແລະwrite. -
path="/var/www/html/file1"- ເສັ້ນທາງໄປຫາວັດຖຸ (ເປົ້າໝາຍ) ທີ່ process ພະຍາຍາມເຂົ້າເຖິງ. -
scontext="unconfined_u:system_r:httpd_t:s0"- ບໍລິບົດ (context) SELinux ຂອງ process (ຕົ້ນທາງ) ທີ່ພະຍາຍາມເຮັດການກະທຳທີ່ຖືກປະຕິເສດ. ໃນກໍລະນີນີ້, ມັນແມ່ນ context SELinux ຂອງ Apache HTTP Server ເຊິ່ງກຳລັງເຮັດວຽກດ້ວຍປະເພດhttpd_t. -
tcontext="unconfined_u:object_r:samba_share_t:s0"- ບໍລິບົດ (context) SELinux ຂອງວັດຖຸ (ເປົ້າໝາຍ) ທີ່ process ພະຍາມຍາມເຂົ້າເຖິງ. ໃນກໍລະນີນີ້, ມັນແມ່ນ context SELinux ຂອງfile1.
ການປະຕິເສດຂອງ SELinux ນີ້ສາມາດແປໄດ້ວ່າ:
SELinux ໄດ້ປະຕິເສດ process httpd ທີ່ມີ PID 2465 ບໍ່ໃຫ້ເຂົ້າເຖິງໄຟລ໌ /var/www/html/file1 ທີ່ມີປະເພດ samba_share_t, ເຊິ່ງ process ທີ່ເຮັດວຽກໃນ domain httpd_t ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ ນອກຈາກຈະມີການກຳນົດຄ່າໄວ້ເປັນຢ່າງອື່ນ.
ແຫຼ່ງຂໍ້ມູນເພີ່ມເຕີມ
-
ໜ້າ man page ຂອງ
auditd(8)ແລະausearch(8)
Want to help? Learn how to contribute to Fedora Docs ›