ການແກ້ໄຂບັນຫາທີ່ກ່ຽວຂ້ອງກັບ SELinux

Mat McCabe, Joe Walker, Peter Boy (pboy) Version F36 and newer Last review: 2023-06-18

ຖ້າທ່ານວາງແຜນທີ່ຈະເປີດໃຊ້ SELinux ໃນລະບົບທີ່ເຄີຍຖືກປິດໄວ້ກ່ອນໜ້ານີ້ ຫຼື ຖ້າທ່ານໃຊ້ບໍລິການໃນການກຳນົດຄ່າທີ່ບໍ່ແມ່ນມາດຕະຖານ, ທ່ານອາດຈະຕ້ອງແກ້ໄຂບັນຫາໃນສະຖານະການທີ່ອາດຈະຖືກບລັອກໂດຍ SELinux. ໝາຍເຫດວ່າໃນກໍລະນີສ່ວນໃຫຍ່, ການປະຕິເສດຈາກ SELinux ແມ່ນສັນຍານຂອງການກຳນົດຄ່າທີ່ຜິດພາດ.

ການລະບຸການປະຕິເສດຂອງ SELinux

ປະຕິບັດຕາມຂັ້ນຕອນທີ່ຈຳເປັນເທົ່ານັ້ນ; ໃນກໍລະນີສ່ວນໃຫຍ່, ທ່ານພຽງແຕ່ຕ້ອງເຮັດຂັ້ນຕອນທີ 1.

ຂັ້ນຕອນການປະຕິບັດ

  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 ອີກຄັ້ງ.

  2. ໃນກໍລະນີທີ່ auditd ກຳລັງເຮັດວຽກຢູ່, ແຕ່ບໍ່ມີຂໍ້ມູນທີ່ກົງກັນໃນຜົນຂອງ ausearch, ໃຫ້ກວດສອບຂໍ້ຄວາມທີ່ສະໜອງໂດຍ systemd Journal:

    $ sudo journalctl -t setroubleshoot
  3. ຖ້າ SELinux ເປີດໃຊ້ງານຢູ່ ແລະ Audit daemon ບໍ່ໄດ້ເຮັດວຽກໃນລະບົບຂອງທ່ານ, ໃຫ້ຄົ້ນຫາຂໍ້ຄວາມ SELinux ບາງຢ່າງໃນຜົນຂອງຄຳສັ່ງ dmesg:

    $ sudo dmesg | grep -i -e type=1300 -e type=1400
  4. ເຖິງແມ່ນວ່າຈະມີການກວດສອບສາມຢ່າງຂ້າງເທິງແລ້ວ, ກໍຍັງເປັນໄປໄດ້ວ່າທ່ານອາດຈະບໍ່ພົບຫຍັງເລີຍ. ໃນກໍລະນີນີ້, ການປະຕິເສດຈາກ AVC ອາດຈະຖືກປິດສຽງໄວ້ເນື່ອງຈາກກົດ dontaudit.

    ເພື່ອປິດໃຊ້ງານກົດ dontaudit ຊົ່ວຄາວ, ເພື່ອອະນຸຍາດໃຫ້ບັນທຶກການປະຕິເສດທັງໝົດ:

    $ sudo semodule -DB

    ຫຼັງຈາກທີ່ທ່ານລອງສະຖານະການທີ່ຖືກປະຕິເສດຄືນໃໝ່ ແລະ ພົບຂໍ້ຄວາມການປະຕິເສດໂດຍໃຊ້ຂັ້ນຕອນກ່ອນໜ້ານີ້, ຄຳສັ່ງຕໍ່ໄປນີ້ຈະເປີດໃຊ້ງານກົດ dontaudit ໃນນະໂຍບາຍອີກຄັ້ງ:

    $ sudo semodule -B
  5. ຖ້າທ່ານໄດ້ປະຕິບັດຕາມທັງສີ່ຂັ້ນຕອນກ່ອນໜ້ານີ້ແລ້ວ ແລະ ບັນຫາຍັງບໍ່ຖືກລະບຸ, ໃຫ້ພິຈາລະນາເບິ່ງວ່າ SELinux ໄດ້ບລັອກສະຖານະການຂອງທ່ານແທ້ຫຼືບໍ່:

    • ປ່ຽນເປັນໂໝດ permissive:

      $ sudo setenforce 0
      $ getenforce
      Permissive
    • ເຮັດຊ້ຳສະຖານະການຂອງທ່ານ.

ຖ້າບັນຫາຍັງເກີດຂຶ້ນຢູ່, ສະແດງວ່າສິ່ງອື່ນທີ່ບໍ່ແມ່ນ SELinux ກຳລັງບລັອກສະຖານະການຂອງທ່ານ.

ການວິເຄາະຂໍ້ຄວາມການປະຕິເສດຂອງ SELinux

ຫຼັງຈາກລະບຸໄດ້ວ່າ SELinux ກຳລັງບລັອກສະຖານະການຂອງທ່ານ, ທ່ານອາດຈະຕ້ອງວິເຄາະສາເຫດຕົ້ນຕໍກ່ອນທີ່ຈະເລືອກວິທີແກ້ໄຂ.

ສິ່ງທີ່ຕ້ອງມີກ່ອນ

  • ແພັກເກດ policycoreutils-python-utils ແລະ setroubleshoot-server ຖືກຕິດຕັ້ງຢູ່ໃນລະບົບຂອງທ່ານແລ້ວ.

ຂັ້ນຕອນການປະຕິບັດ

  1. ສະແດງລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການປະຕິເສດທີ່ຖືກບັນທຶກໄວ້ໂດຍໃຊ້ຄຳສັ່ງ 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
  2. ຖ້າຜົນທີ່ໄດ້ຮັບໃນຂັ້ນຕອນກ່ອນໜ້ານີ້ບໍ່ມີຄຳແນະນຳທີ່ຊັດເຈນ:

    • ເປີດໃຊ້ການກວດສອບເສັ້ນທາງເຕັມ (full-path auditing) ເພື່ອເບິ່ງເສັ້ນທາງເຕັມຂອງວັດຖຸທີ່ຖືກເຂົ້າເຖິງ ແລະ ເຮັດໃຫ້ເຫັນຟິລເຫດການ Linux Audit ເພີ່ມເຕີມ:

      $ sudo auditctl -w /etc/shadow -p w -k shadow-write
    • ລຶບ setroubleshoot cache:

      $ sudo rm -f /var/lib/setroubleshoot/setroubleshoot.xml
    • ເຮັດໃຫ້ບັນຫາເກີດຂຶ້ນຊ້ຳອີກຄັ້ງ.

    • ເຮັດຊ້ຳຂັ້ນຕອນທີ 1.

      ຫຼັງຈາກສິ້ນສຸດຂັ້ນຕອນ, ໃຫ້ປິດການກວດສອບເສັ້ນທາງເຕັມ:

      $ sudo auditctl -W /etc/shadow -p w -k shadow-write
  3. ຖ້າ 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)