ການປະຕິເສດການເຂົ້າເຖິງ HTTP ທີ່ Squid ສ້າງຂຶ້ນ ແລະ “Permission denied” ຂອງລະບົບປະຕິບັດການ ເກີດຂຶ້ນຢູ່ຂອບເຂດທີ່ແຕກຕ່າງກັນ. ກຳນົດວ່າ Squid ກຳລັງເປີດໄຟລ໌, ຜູກຊັອກເກັດ, ເຊື່ອມຕໍ່ອອກພາຍນອກ ຫຼື ປະຕິເສດຄຳຮ້ອງຂອງລູກຄ້າ.

ເຊື່ອມໂຍງເຫດການກວດສອບ

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

ພອດຮັບຟັງທີ່ກຳນົດເອງອາດຕ້ອງການປ້າຍພອດທີ່ສອດຄ້ອງ. ໄດເລັກທໍລີບັນທຶກ ຫຼື ແຄດທີ່ຍ້າຍໄປອາດຕ້ອງການການຕິດປ້າຍໄຟລ໌. ສຳລັບຄວາມລົ້ມເຫຼວຂອງເສັ້ນທາງບັນທຶກຂອງ Squid, ໃຫ້ກວດສອບ ການຜ່ານໄດເລັກທໍລີ ແລະ ສິດຂອງຜູ້ຂຽນ ນຳ ກ່ອນທີ່ຈະໂທດປ້າຍ. ສິດສຳລັບບໍລິການອອກພາຍນອກທີ່ຜິດປົກກະຕິແມ່ນການດຳເນີນການອີກຢ່າງໜຶ່ງ; ຕົວຢ່າງ Squid SELinux ຂອງ Red Hat ແຍກກໍລະນີເຫຼົ່ານີ້.

ໃຊ້ນະໂຍບາຍຂອງການແຈກຢາຍທີ່ຕິດຕັ້ງ ແລະ ຄຳແນະນຳການບໍລິຫານ. ເສັ້ນທາງແພັກເກດ, ປ້າຍ ແລະ ການຈຳກັດອາດແຕກຕ່າງກັນລະຫວ່າງອິມເມຈ. ໃນລະບົບທີ່ໃຊ້ AppArmor, ໃຫ້ກວດເບິ່ງໂປຣໄຟລ໌ຂອງມັນ ແທນທີ່ຈະໃຊ້ຄຳສັ່ງ SELinux.

ແກ້ໄຂນະໂຍບາຍ ຫຼື ຕຳແໜ່ງທີ່ຫຼັກຖານຊີ້ໄປ ໃນຂະນະທີ່ຮັກສາການບັງຄັບໃຊ້ໃນໂຮສ. ການກວດສອບລູກຄ້າ ແລະ ກົດການເຂົ້າເຖິງຂອງ Squid ເອງ ຍັງໃຊ້ໄດ້ຢູ່ ຫຼັງຈາກແກ້ໄຂບັນຫານະໂຍບາຍຂອງໂຮສແລ້ວ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ