ປື້ມ "BPF ສໍາລັບການຕິດຕາມ Linux"

ສະບາຍດີຊາວ Khabro! ເຄື່ອງ virtual BPF ແມ່ນຫນຶ່ງໃນອົງປະກອບທີ່ສໍາຄັນທີ່ສຸດຂອງ Linux kernel. ການນໍາໃຊ້ທີ່ເຫມາະສົມຂອງມັນຈະຊ່ວຍໃຫ້ວິສະວະກອນລະບົບສາມາດຊອກຫາຂໍ້ບົກພ່ອງແລະແກ້ໄຂບັນຫາທີ່ສັບສົນທີ່ສຸດ. ທ່ານຈະຮຽນຮູ້ວິທີການຂຽນໂປລແກລມທີ່ຕິດຕາມແລະດັດແປງພຶດຕິກໍາຂອງ kernel, ວິທີການປະຕິບັດລະຫັດຢ່າງປອດໄພເພື່ອຕິດຕາມເຫດການໃນ kernel, ແລະອື່ນໆອີກ. David Calavera ແລະ Lorenzo Fontana ຈະຊ່ວຍໃຫ້ທ່ານປົດລັອກພະລັງງານຂອງ BPF. ຂະຫຍາຍຄວາມຮູ້ຂອງທ່ານກ່ຽວກັບການເພີ່ມປະສິດທິພາບ, ເຄືອຂ່າຍ, ຄວາມປອດໄພ. - ໃຊ້ BPF ເພື່ອຕິດຕາມແລະດັດແປງພຶດຕິກໍາຂອງ Linux kernel. - ໃສ່ລະຫັດເພື່ອຕິດຕາມເຫດການ kernel ຢ່າງປອດໄພໂດຍບໍ່ຈໍາເປັນຕ້ອງລວບລວມ kernel ຫຼື reboot ລະບົບ. — ໃຊ້ຕົວຢ່າງລະຫັດທີ່ສະດວກໃນ C, Go ຫຼື Python. - ຄວບຄຸມໂດຍການເປັນເຈົ້າຂອງໂຄງການ BPF.

Linux Kernel Security, ຄຸນສົມບັດຂອງມັນ ແລະ Seccomp

BPF ສະຫນອງວິທີການທີ່ມີປະສິດທິພາບໃນການຂະຫຍາຍແກ່ນຂອງແກ່ນໂດຍບໍ່ມີການເສຍສະລະຄວາມຫມັ້ນຄົງ, ຄວາມປອດໄພ, ຫຼືຄວາມໄວ. ສໍາລັບເຫດຜົນນີ້, ນັກພັດທະນາ kernel ຄິດວ່າມັນເປັນຄວາມຄິດທີ່ດີທີ່ຈະໃຊ້ຄວາມຍືດຫຍຸ່ນຂອງມັນເພື່ອປັບປຸງການໂດດດ່ຽວຂອງຂະບວນການໃນ Seccomp ໂດຍການປະຕິບັດຕົວກອງ Seccomp ສະຫນັບສະຫນູນໂດຍໂຄງການ BPF, ເຊິ່ງເອີ້ນກັນວ່າ Seccomp BPF. ໃນບົດນີ້ພວກເຮົາຈະອະທິບາຍວ່າ Seccomp ແມ່ນຫຍັງແລະມັນຖືກນໍາໃຊ້ແນວໃດ. ຫຼັງຈາກນັ້ນ, ທ່ານຈະຮຽນຮູ້ວິທີການຂຽນຕົວກອງ Seccomp ໂດຍໃຊ້ໂປແກຼມ BPF. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະເບິ່ງ hooks BPF ທີ່ມີຢູ່ໃນຕົວທີ່ລວມຢູ່ໃນ kernel ສໍາລັບໂມດູນຄວາມປອດໄພ Linux.

ໂມດູນຄວາມປອດໄພ Linux (LSM) ແມ່ນກອບທີ່ສະຫນອງຊຸດຂອງຫນ້າທີ່ສາມາດນໍາໃຊ້ເພື່ອປະຕິບັດຮູບແບບຄວາມປອດໄພຕ່າງໆໃນລັກສະນະມາດຕະຖານ. LSM ສາມາດຖືກນໍາໃຊ້ໂດຍກົງໃນຕົ້ນແຫຼ່ງແກ່ນ, ເຊັ່ນ Apparmor, SELinux ແລະ Tomoyo.

ໃຫ້ເລີ່ມຕົ້ນໂດຍການສົນທະນາຄວາມສາມາດຂອງ Linux.

ຄຸນນະສົມບັດ

ໂດຍເນື້ອແທ້ແລ້ວຂອງຄວາມສາມາດຂອງ Linux ແມ່ນວ່າທ່ານຕ້ອງການອະນຸຍາດໃຫ້ຂະບວນການທີ່ບໍ່ມີສິດທິພິເສດເພື່ອປະຕິບັດວຽກງານສະເພາະໃດຫນຶ່ງ, ແຕ່ໂດຍບໍ່ມີການນໍາໃຊ້ suid ສໍາລັບຈຸດປະສົງນັ້ນ, ຖ້າບໍ່ດັ່ງນັ້ນເຮັດໃຫ້ຂະບວນການມີສິດ, ຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງການໂຈມຕີແລະອະນຸຍາດໃຫ້ຂະບວນການປະຕິບັດວຽກງານສະເພາະໃດຫນຶ່ງ. ຕົວຢ່າງ, ຖ້າຄໍາຮ້ອງສະຫມັກຂອງທ່ານຕ້ອງການເປີດພອດທີ່ມີສິດທິພິເສດ, ເວົ້າວ່າ 80, ແທນທີ່ຈະດໍາເນີນການຂະບວນການເປັນຮາກ, ທ່ານພຽງແຕ່ສາມາດໃຫ້ມັນ CAP_NET_BIND_SERVICE ຄວາມສາມາດ.

ພິຈາລະນາໂຄງການ Go ທີ່ມີຊື່ວ່າ main.go:

package main
import (
            "net/http"
            "log"
)
func main() {
     log.Fatalf("%v", http.ListenAndServe(":80", nil))
}

ໂປລແກລມນີ້ໃຫ້ບໍລິການເຄື່ອງແມ່ຂ່າຍ HTTP ໃນພອດ 80 (ນີ້ແມ່ນພອດທີ່ມີສິດທິພິເສດ). ປົກກະຕິແລ້ວພວກເຮົາດໍາເນີນການມັນທັນທີຫຼັງຈາກການລວບລວມ:

$ go build -o capabilities main.go
$ ./capabilities

ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກພວກເຮົາບໍ່ໄດ້ໃຫ້ສິດທິ root, ລະຫັດນີ້ຈະຖິ້ມຄວາມຜິດພາດໃນເວລາທີ່ຜູກມັດພອດ:

2019/04/25 23:17:06 listen tcp :80: bind: permission denied
exit status 1

capsh (ຜູ້ຈັດການແກະ) ແມ່ນເຄື່ອງມືທີ່ດໍາເນີນການ shell ທີ່ມີຊຸດຄວາມສາມາດສະເພາະ.

ໃນກໍລະນີນີ້, ດັ່ງທີ່ໄດ້ກ່າວມາແລ້ວ, ແທນທີ່ຈະໃຫ້ສິດຮາກຢ່າງເຕັມທີ່, ທ່ານສາມາດເປີດໃຊ້ການຜູກມັດພອດທີ່ມີສິດທິພິເສດໂດຍການສະຫນອງຄວາມສາມາດຂອງ cap_net_bind_service ພ້ອມກັບສິ່ງອື່ນທີ່ມີຢູ່ໃນໂຄງການ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາສາມາດປິດໂຄງການຂອງພວກເຮົາໃນ capsh:

# capsh --caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' 
   --keep=1 --user="nobody" 
   --addamb=cap_net_bind_service -- -c "./capabilities"

ໃຫ້ເຂົ້າໃຈທີມງານນີ້ເລັກນ້ອຍ.

• capsh - ໃຊ້ capsh ເປັນແກະ.
• —caps='cap_net_bind_service+eip cap_setpcap,cap_setuid,cap_setgid+ep' - ເນື່ອງຈາກພວກເຮົາຕ້ອງການປ່ຽນຜູ້ໃຊ້ (ພວກເຮົາບໍ່ຕ້ອງການໃຊ້ເປັນ root), ພວກເຮົາຈະລະບຸ cap_net_bind_service ແລະຄວາມສາມາດໃນການປ່ຽນລະຫັດຜູ້ໃຊ້ຕົວຈິງຈາກ ຮາກໄປຫາບໍ່ມີໃຜ, ຄື cap_setuid ແລະ cap_setgid.
• —keep=1 — ພວກ​ເຮົາ​ຕ້ອງ​ການ​ທີ່​ຈະ​ຮັກ​ສາ​ຄວາມ​ສາ​ມາດ​ທີ່​ຕິດ​ຕັ້ງ​ໃນ​ເວ​ລາ​ທີ່​ປ່ຽນ​ຈາກ​ບັນ​ຊີ​ຮາກ​.
• —user=“nobody” — ຜູ້​ໃຊ້​ສຸດ​ທ້າຍ​ທີ່​ດໍາ​ເນີນ​ໂຄງ​ການ​ຈະ​ບໍ່​ມີ​ໃຜ.
• —addamb=cap_net_bind_service — ຕັ້ງ​ການ​ລ້າງ​ຄວາມ​ສາ​ມາດ​ທີ່​ກ່ຽວ​ຂ້ອງ​ຫຼັງ​ຈາກ​ການ​ປ່ຽນ​ຈາກ​ຮູບ​ແບບ​ຮາກ​.
• - -c "./capabilities" - ພຽງແຕ່ດໍາເນີນການໂຄງການ.

ຄວາມສາມາດທີ່ເຊື່ອມໂຍງແມ່ນຄວາມສາມາດພິເສດທີ່ສືບທອດມາຈາກບັນດາໂຄງການເດັກນ້ອຍ ເມື່ອໂຄງການປະຈຸບັນປະຕິບັດພວກມັນໂດຍໃຊ້ execve(). ພຽງແຕ່ຄວາມສາມາດທີ່ອະນຸຍາດໃຫ້ເຊື່ອມໂຍງ, ຫຼືໃນຄໍາສັບຕ່າງໆອື່ນໆ, ເປັນຄວາມສາມາດດ້ານສິ່ງແວດລ້ອມ, ສາມາດໄດ້ຮັບການສືບທອດ.

ທ່ານອາດຈະສົງໄສວ່າ +eip ຫມາຍຄວາມວ່າແນວໃດຫຼັງຈາກລະບຸຄວາມສາມາດໃນຕົວເລືອກ --caps. ທຸງເຫຼົ່ານີ້ຖືກນໍາໃຊ້ເພື່ອກໍານົດວ່າຄວາມສາມາດ:

- ຕ້ອງໄດ້ຮັບການກະຕຸ້ນ (p);

- ສາມາດໃຊ້ໄດ້ສໍາລັບການນໍາໃຊ້ (e);

-ສາມາດໄດ້ຮັບການສືບທອດໂດຍຂະບວນການຂອງເດັກ (i).

ເນື່ອງຈາກພວກເຮົາຕ້ອງການໃຊ້ cap_net_bind_service, ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດສິ່ງນີ້ດ້ວຍທຸງ e. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະເລີ່ມຕົ້ນ shell ໃນຄໍາສັ່ງ. ນີ້ຈະດໍາເນີນການສອງຄວາມສາມາດແລະພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຫມາຍມັນດ້ວຍທຸງ i. ສຸດທ້າຍ, ພວກເຮົາຕ້ອງການໃຫ້ຄຸນສົມບັດຖືກເປີດໃຊ້ງານ (ພວກເຮົາໄດ້ເຮັດສິ່ງນີ້ໂດຍບໍ່ມີການປ່ຽນ UID) ກັບ p. ເບິ່ງຄືວ່າ cap_net_bind_service+eip.

ທ່ານສາມາດກວດສອບຜົນໄດ້ຮັບໂດຍໃຊ້ ss. ຂໍໃຫ້ຫຍໍ້ຜົນຜະລິດເລັກນ້ອຍເພື່ອໃຫ້ພໍດີກັບຫນ້າ, ແຕ່ມັນຈະສະແດງພອດທີ່ກ່ຽວຂ້ອງແລະ ID ຜູ້ໃຊ້ອື່ນທີ່ບໍ່ແມ່ນ 0, ໃນກໍລະນີນີ້ 65:

# ss -tulpn -e -H | cut -d' ' -f17-
128 *:80 *:*
users:(("capabilities",pid=30040,fd=3)) uid:65534 ino:11311579 sk:2c v6only:0

ໃນຕົວຢ່າງນີ້ພວກເຮົາໄດ້ໃຊ້ capsh, ແຕ່ທ່ານສາມາດຂຽນ shell ໂດຍໃຊ້ libcap. ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ, ເບິ່ງ man 3 libcap.

ເມື່ອຂຽນໂປຼແກຼມ, ສ່ວນຫຼາຍແລ້ວນັກພັດທະນາບໍ່ຮູ້ລ່ວງ ໜ້າ ຄຸນລັກສະນະທັງ ໝົດ ທີ່ໂຄງການຕ້ອງການໃນເວລາແລ່ນ; ຍິ່ງໄປກວ່ານັ້ນ, ລັກສະນະເຫຼົ່ານີ້ອາດຈະມີການປ່ຽນແປງໃນຮຸ່ນໃຫມ່.

ເພື່ອເຂົ້າໃຈຄວາມສາມາດຂອງໂປແກມຂອງພວກເຮົາໄດ້ດີຂຶ້ນ, ພວກເຮົາສາມາດເອົາເຄື່ອງມື BCC ທີ່ມີຄວາມສາມາດ, ເຊິ່ງກໍານົດ kprobe ສໍາລັບຟັງຊັນ kernel cap_capable:

/usr/share/bcc/tools/capable
TIME      UID  PID   TID   COMM               CAP    NAME           AUDIT
10:12:53 0 424     424     systemd-udevd 12 CAP_NET_ADMIN         1
10:12:57 0 1103   1101   timesync        25 CAP_SYS_TIME         1
10:12:57 0 19545 19545 capabilities       10 CAP_NET_BIND_SERVICE 1

ພວກເຮົາສາມາດບັນລຸສິ່ງດຽວກັນໂດຍໃຊ້ bpftrace ກັບ kprobe ເສັ້ນດຽວໃນຟັງຊັນ kernel cap_capable:

bpftrace -e 
   'kprobe:cap_capable {
      time("%H:%M:%S ");
      printf("%-6d %-6d %-16s %-4d %dn", uid, pid, comm, arg2, arg3);
    }' 
    | grep -i capabilities

ນີ້ຈະສົ່ງຜົນອອກມາເຊັ່ນຕໍ່ໄປນີ້ຖ້າຄວາມສາມາດຂອງໂປຣແກຣມຂອງພວກເຮົາຖືກເປີດໃຊ້ຫຼັງຈາກ kprobe:

12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 21 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 12 0
12:01:56 1000 13524 capabilities 10 1

ຖັນທີຫ້າແມ່ນຄວາມສາມາດທີ່ຂະບວນການຕ້ອງການ, ແລະນັບຕັ້ງແຕ່ຜົນໄດ້ຮັບນີ້ປະກອບມີເຫດການທີ່ບໍ່ແມ່ນການກວດສອບ, ພວກເຮົາເຫັນການກວດສອບທີ່ບໍ່ແມ່ນການກວດສອບທັງຫມົດແລະສຸດທ້າຍແມ່ນຄວາມສາມາດທີ່ກໍານົດໄວ້ກັບທຸງການກວດສອບ (ສຸດທ້າຍໃນຜົນໄດ້ຮັບ) ກໍານົດເປັນ 1. ຄວາມສາມາດ ອັນທີ່ພວກເຮົາສົນໃຈແມ່ນ CAP_NET_BIND_SERVICE, ມັນຖືກກໍານົດເປັນຄ່າຄົງທີ່ໃນລະຫັດແຫຼ່ງ kernel ໃນໄຟລ໌ include/uapi/linux/ability.h ກັບຕົວລະບຸ 10:

/* Allows binding to TCP/UDP sockets below 1024 */
/* Allows binding to ATM VCIs below 32 */
#define CAP_NET_BIND_SERVICE 10<source lang="go">

ຄວາມສາມາດມັກຈະຖືກເປີດໃຊ້ໃນ runtime ສໍາລັບ containers ເຊັ່ນ runC ຫຼື Docker ເພື່ອອະນຸຍາດໃຫ້ພວກເຂົາດໍາເນີນການໃນໂຫມດທີ່ບໍ່ມີສິດທິພິເສດ, ແຕ່ພວກເຂົາໄດ້ຮັບອະນຸຍາດໃຫ້ພຽງແຕ່ຄວາມສາມາດທີ່ຈໍາເປັນເພື່ອດໍາເນີນການຄໍາຮ້ອງສະຫມັກສ່ວນໃຫຍ່. ເມື່ອແອັບພລິເຄຊັນຕ້ອງການຄວາມສາມາດທີ່ແນ່ນອນ, Docker ສາມາດສະໜອງໃຫ້ເຂົາເຈົ້າໂດຍໃຊ້ --cap-add:

docker run -it --rm --cap-add=NET_ADMIN ubuntu ip link add dummy0 type dummy

ຄໍາສັ່ງນີ້ຈະໃຫ້ບັນຈຸມີຄວາມສາມາດ CAP_NET_ADMIN, ເຮັດໃຫ້ມັນສາມາດກໍາຫນົດຄ່າການເຊື່ອມຕໍ່ເຄືອຂ່າຍເພື່ອເພີ່ມການໂຕ້ຕອບ dummy0.

ພາກຕໍ່ໄປສະແດງໃຫ້ເຫັນວິທີການນໍາໃຊ້ຄຸນນະສົມບັດເຊັ່ນການກັ່ນຕອງ, ແຕ່ການນໍາໃຊ້ເຕັກນິກທີ່ແຕກຕ່າງກັນທີ່ອະນຸຍາດໃຫ້ພວກເຮົາປະຕິບັດໂຄງການຕົວກອງຂອງພວກເຮົາເອງ.

Seccomp

Seccomp ຫຍໍ້ມາຈາກ Secure Computing ແລະເປັນຊັ້ນຄວາມປອດໄພທີ່ປະຕິບັດຢູ່ໃນ Linux kernel ທີ່ອະນຸຍາດໃຫ້ນັກພັດທະນາສາມາດກັ່ນຕອງການໂທລະບົບບາງຢ່າງ. ເຖິງແມ່ນວ່າ Seccomp ມີຄວາມສາມາດປຽບທຽບກັບ Linux, ຄວາມສາມາດໃນການຈັດການການໂທລະບົບບາງຢ່າງເຮັດໃຫ້ມັນມີຄວາມຍືດຫຍຸ່ນຫຼາຍເມື່ອທຽບກັບພວກມັນ.

ຄຸນສົມບັດຂອງ Seccomp ແລະ Linux ບໍ່ແມ່ນສະເພາະເຊິ່ງກັນແລະກັນ ແລະມັກຈະຖືກນໍາໃຊ້ຮ່ວມກັນເພື່ອຮັບຜົນປະໂຫຍດຈາກທັງສອງວິທີການ. ຕົວຢ່າງ, ທ່ານອາດຈະຕ້ອງການໃຫ້ຂະບວນການ CAP_NET_ADMIN ຄວາມສາມາດແຕ່ບໍ່ໃຫ້ມັນຍອມຮັບການເຊື່ອມຕໍ່ຊັອກເກັດ, ຂັດຂວາງການຍອມຮັບແລະຍອມຮັບການໂທລະບົບ 4.

ວິທີການການກັ່ນຕອງ Seccomp ແມ່ນອີງໃສ່ຕົວກອງ BPF ທີ່ດໍາເນີນການຢູ່ໃນໂຫມດ SECCOMP_MODE_FILTER, ແລະການກັ່ນຕອງການໂທລະບົບແມ່ນດໍາເນີນໃນແບບດຽວກັນກັບແພັກເກັດ.

ຕົວກອງ Seccomp ຖືກໂຫລດໂດຍໃຊ້ prctl ຜ່ານການດໍາເນີນງານ PR_SET_SECOMP. ການກັ່ນຕອງເຫຼົ່ານີ້ໃຊ້ຮູບແບບຂອງໂຄງການ BPF ທີ່ຖືກປະຕິບັດສໍາລັບແຕ່ລະຊຸດ Seccomp ທີ່ສະແດງໂດຍໂຄງສ້າງ seccomp_data. ໂຄງສ້າງນີ້ປະກອບດ້ວຍສະຖາປັດຕະຍະກໍາອ້າງອີງ, ຄໍາແນະນໍາຂອງຕົວຊີ້ໄປຫາໂປເຊດເຊີໃນເວລາທີ່ໂທຫາລະບົບ, ແລະສູງສຸດຂອງຫົກການໂຕ້ຖຽງການໂທລະບົບ, ສະແດງເປັນ uint64.

ນີ້ແມ່ນສິ່ງທີ່ໂຄງສ້າງ seccomp_data ຄ້າຍຄືຈາກລະຫັດແຫຼ່ງ kernel ໃນໄຟລ໌ linux/seccomp.h:

struct seccomp_data {
int nr;
      __u32 arch;
      __u64 instruction_pointer;
      __u64 args[6];
};

ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້ຈາກໂຄງສ້າງນີ້, ພວກເຮົາສາມາດກັ່ນຕອງໂດຍການໂທຫາລະບົບ, ການໂຕ້ຖຽງຂອງມັນ, ຫຼືການປະສົມປະສານຂອງທັງສອງ.

ຫຼັງຈາກໄດ້ຮັບແຕ່ລະຊຸດ Seccomp, ການກັ່ນຕອງຕ້ອງດໍາເນີນການປຸງແຕ່ງເພື່ອຕັດສິນໃຈສຸດທ້າຍແລະບອກ kernel ວ່າຈະເຮັດແນວໃດຕໍ່ໄປ. ການຕັດສິນໃຈສຸດທ້າຍແມ່ນສະແດງອອກໂດຍຫນຶ່ງໃນມູນຄ່າກັບຄືນ (ລະຫັດສະຖານະ).

- SECOMP_RET_KILL_PROCESS - ຂ້າຂະບວນການທັງຫມົດໃນທັນທີຫຼັງຈາກການກັ່ນຕອງການໂທລະບົບທີ່ບໍ່ໄດ້ຖືກປະຕິບັດເນື່ອງຈາກວ່ານີ້.

- SECOMP_RET_KILL_THREAD - ສິ້ນສຸດກະທູ້ປະຈຸບັນທັນທີຫຼັງຈາກການກັ່ນຕອງການໂທລະບົບທີ່ບໍ່ໄດ້ດໍາເນີນການເນື່ອງຈາກວ່ານີ້.

— SECOMP_RET_KILL — ນາມແຝງສຳລັບ SECOMP_RET_KILL_THREAD, ໄວ້ເພື່ອຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງ.

- SECOMP_RET_TRAP - ການໂທຫາລະບົບຖືກຫ້າມ, ແລະສັນຍານ SIGSYS (Bad System Call) ຖືກສົ່ງໄປຫາວຽກທີ່ໂທຫາມັນ.

- SECOMP_RET_ERRNO - ການໂທລະບົບບໍ່ໄດ້ຖືກປະຕິບັດ, ແລະສ່ວນຫນຶ່ງຂອງ SECOMP_RET_DATA ການກັ່ນຕອງຄືນຄ່າຖືກສົ່ງກັບພື້ນທີ່ຜູ້ໃຊ້ເປັນຄ່າ errno. ອີງຕາມສາເຫດຂອງຄວາມຜິດພາດ, ຄ່າ errno ທີ່ແຕກຕ່າງກັນຖືກສົ່ງຄືນ. ບັນຊີລາຍຊື່ຂອງຕົວເລກຄວາມຜິດພາດແມ່ນສະຫນອງໃຫ້ຢູ່ໃນພາກຕໍ່ໄປ.

- SECOMP_RET_TRACE - ໃຊ້ເພື່ອແຈ້ງເຕືອນ ptrace tracer ໂດຍໃຊ້ - PTRACE_O_TRACESECCOMP ເພື່ອຂັດຂວາງເມື່ອການໂທລະບົບຖືກປະຕິບັດເພື່ອເບິ່ງແລະຄວບຄຸມຂະບວນການນັ້ນ. ຖ້າ tracer ບໍ່ໄດ້ເຊື່ອມຕໍ່, ຂໍ້ຜິດພາດຈະຖືກສົ່ງຄືນ, errno ຖືກຕັ້ງເປັນ -ENOSYS, ແລະການໂທຫາລະບົບບໍ່ໄດ້ດໍາເນີນການ.

- SECOMP_RET_LOG - ການໂທລະບົບຖືກແກ້ໄຂ ແລະເຂົ້າລະບົບແລ້ວ.

- SECOMP_RET_ALLOW - ການໂທລະບົບແມ່ນອະນຸຍາດຢ່າງງ່າຍດາຍ.

ptrace ແມ່ນການເອີ້ນລະບົບເພື່ອປະຕິບັດກົນໄກການຕິດຕາມໃນຂະບວນການທີ່ເອີ້ນວ່າ tracee, ມີຄວາມສາມາດຕິດຕາມແລະຄວບຄຸມການປະຕິບັດຂອງຂະບວນການ. ໂປຣແກມ trace ສາມາດມີອິດທິພົນຕໍ່ການປະຕິບັດ ແລະດັດແປງການລົງທະບຽນຄວາມຊົງຈຳຂອງ tracee. ໃນບໍລິບົດ Seccomp, ptrace ຖືກນໍາໃຊ້ເມື່ອຖືກກະຕຸ້ນໂດຍລະຫັດສະຖານະ SECOMP_RET_TRACE, ດັ່ງນັ້ນ tracer ສາມາດປ້ອງກັນການໂທລະບົບຈາກການປະຕິບັດແລະປະຕິບັດເຫດຜົນຂອງຕົນເອງ.

ຄວາມຜິດພາດ Seccomp

ໃນບາງເວລາ, ໃນຂະນະທີ່ເຮັດວຽກກັບ Seccomp, ທ່ານຈະພົບກັບຂໍ້ຜິດພາດຕ່າງໆ, ເຊິ່ງຖືກກໍານົດໂດຍຄ່າກັບຄືນຂອງປະເພດ SECOMP_RET_ERRNO. ເພື່ອລາຍງານຂໍ້ຜິດພາດ, ການໂທລະບົບ seccomp ຈະກັບຄືນ -1 ແທນ 0.

ຄວາມຜິດພາດຕໍ່ໄປນີ້ແມ່ນເປັນໄປໄດ້:

- EACCESS - ຜູ້ໂທບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ໂທຫາລະບົບ. ນີ້ມັກຈະເກີດຂຶ້ນເນື່ອງຈາກວ່າມັນບໍ່ມີສິດທິ CAP_SYS_ADMIN ຫຼື no_new_privs ບໍ່ໄດ້ຖືກກໍານົດໂດຍໃຊ້ prctl (ພວກເຮົາຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ຕໍ່ມາ);

— EFAULT — ການໂຕ້ຖຽງທີ່ຜ່ານ (args ໃນໂຄງສ້າງ seccomp_data) ບໍ່ມີທີ່ຢູ່ທີ່ຖືກຕ້ອງ;

— EINVAL — ສາ​ມາດ​ມີ​ສີ່​ເຫດ​ຜົນ​ທີ່​ນີ້​:

- ການດໍາເນີນງານທີ່ຮ້ອງຂໍແມ່ນບໍ່ຮູ້ຈັກຫຼືບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນໂດຍ kernel ໃນການຕັ້ງຄ່າປະຈຸບັນ;

- ທຸງທີ່ລະບຸໄວ້ບໍ່ຖືກຕ້ອງສໍາລັບການປະຕິບັດງານທີ່ຮ້ອງຂໍ;

-operation ປະກອບມີ BPF_ABS, ແຕ່ມີບັນຫາກັບການຊົດເຊີຍທີ່ລະບຸໄວ້, ເຊິ່ງອາດຈະເກີນຂະຫນາດຂອງໂຄງສ້າງ seccomp_data;

- ຈໍານວນຂອງຄໍາແນະນໍາທີ່ສົ່ງກັບການກັ່ນຕອງເກີນສູງສຸດ;

— ENOMEM — ບໍ່​ມີ​ຄວາມ​ຊົງ​ຈໍາ​ພຽງ​ພໍ​ທີ່​ຈະ​ປະ​ຕິ​ບັດ​ໂຄງ​ການ​;

- EOPNOTSUPP - ການດໍາເນີນງານຊີ້ໃຫ້ເຫັນວ່າກັບ SECCOMP_GET_ACTION_AVAIL ການປະຕິບັດແມ່ນມີຢູ່, ແຕ່ kernel ບໍ່ສະຫນັບສະຫນູນຜົນຕອບແທນໃນການໂຕ້ຖຽງ;

— ESRCH — ບັນ​ຫາ​ໄດ້​ເກີດ​ຂຶ້ນ​ໃນ​ເວ​ລາ​ທີ່ synchronizing ສາຍ​ນ​້​ໍ​ອື່ນ​;

- ENOSYS - ບໍ່ມີຕົວຕິດຕາມທີ່ຕິດກັບຄຳສັ່ງ SECOMP_RET_TRACE.

prctl ແມ່ນການເອີ້ນລະບົບທີ່ອະນຸຍາດໃຫ້ໂຄງການພື້ນທີ່ຜູ້ໃຊ້ສາມາດຈັດການ (ກໍານົດແລະຮັບ) ລັກສະນະສະເພາະຂອງຂະບວນການ, ເຊັ່ນ: byte endianness, ຊື່ thread, ຮູບແບບການຄິດໄລ່ທີ່ປອດໄພ (Seccomp), ສິດທິພິເສດ, ເຫດການ Perf, ແລະອື່ນໆ.

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

ຕົວຢ່າງຕົວກອງ BPF Seccomp

ໃນ​ທີ່​ນີ້​ພວກ​ເຮົາ​ຈະ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ວິ​ທີ​ການ​ສົມ​ທົບ​ສອງ​ການ​ປະ​ຕິ​ບັດ​ທີ່​ໄດ້​ປຶກ​ສາ​ຫາ​ລື​ກ່ອນ​ຫນ້າ​ນີ້​, ຄື​:

— ພວກ​ເຮົາ​ຈະ​ຂຽນ​ໂຄງ​ການ Seccomp BPF​, ເຊິ່ງ​ຈະ​ຖືກ​ນໍາ​ໃຊ້​ເປັນ​ຕົວ​ກັ່ນ​ຕອງ​ທີ່​ມີ​ລະ​ຫັດ​ຜົນ​ຕອບ​ແທນ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຂຶ້ນ​ກັບ​ການ​ຕັດ​ສິນ​ໃຈ​ໄດ້​;

- ໂຫຼດຕົວກອງໂດຍໃຊ້ prctl.

ທໍາອິດທ່ານຕ້ອງການ headers ຈາກຫ້ອງສະຫມຸດມາດຕະຖານແລະ Linux kernel:

#include <errno.h>
#include <linux/audit.h>
#include <linux/bpf.h>
#include <linux/filter.h>
#include <linux/seccomp.h>
#include <linux/unistd.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/prctl.h>
#include <unistd.h>

ກ່ອນທີ່ຈະພະຍາຍາມຕົວຢ່າງນີ້, ພວກເຮົາຕ້ອງຮັບປະກັນວ່າ kernel ໄດ້ຖືກລວບລວມດ້ວຍ CONFIG_SECCOMP ແລະ CONFIG_SECOMP_FILTER ຕັ້ງເປັນ y. ໃນເຄື່ອງທີ່ເຮັດວຽກທ່ານສາມາດກວດສອບໄດ້ເຊັ່ນນີ້:

cat /proc/config.gz| zcat | grep -i CONFIG_SECCOMP

ສ່ວນທີ່ເຫຼືອຂອງລະຫັດແມ່ນຫນ້າທີ່ຕິດຕັ້ງ_filter ສອງສ່ວນ. ສ່ວນທໍາອິດມີບັນຊີລາຍຊື່ຄໍາແນະນໍາການກັ່ນຕອງ BPF ຂອງພວກເຮົາ:

static int install_filter(int nr, int arch, int error) {
  struct sock_filter filter[] = {
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, arch))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3),
    BPF_STMT(BPF_LD + BPF_W + BPF_ABS, (offsetof(struct seccomp_data, nr))),
    BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ERRNO | (error & SECCOMP_RET_DATA)),
    BPF_STMT(BPF_RET + BPF_K, SECCOMP_RET_ALLOW),
  };

ຄຳແນະນຳຖືກຕັ້ງໂດຍໃຊ້ມາໂຄ BPF_STMT ແລະ BPF_JUMP ທີ່ກຳນົດໄວ້ໃນໄຟລ໌ linux/filter.h.
ໃຫ້ໄປໂດຍຜ່ານຄໍາແນະນໍາ.

- BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, arch)))) - ລະບົບຈະໂຫຼດ ແລະສະສົມຈາກ BPF_LD ໃນຮູບແບບຂອງຄຳວ່າ BPF_W, ຂໍ້ມູນແພັກເກັດຕັ້ງຢູ່ໃນຄ່າຊົດເຊີຍຄົງທີ່ BPF_ABS.

- BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, arch, 0, 3) - ກວດສອບໂດຍໃຊ້ BPF_JEQ ວ່າຄ່າສະຖາປັດຕະຍະກຳໃນ BPF_K accumulator ຄົງທີ່ເທົ່າກັບ arch. ຖ້າເປັນດັ່ງນັ້ນ, ໂດດຢູ່ທີ່ offset 0 ໄປຫາຄໍາແນະນໍາຕໍ່ໄປ, ຖ້າບໍ່ດັ່ງນັ້ນກະໂດດຢູ່ທີ່ offset 3 (ໃນກໍລະນີນີ້) ເພື່ອຖິ້ມຄວາມຜິດພາດເພາະວ່າ arch ບໍ່ກົງກັນ.

- BPF_STMT(BPF_LD + BPF_W + BPF_ABS (offsetof(struct seccomp_data, nr)))) - ໂຫຼດ ແລະສະສົມຈາກ BPF_LD ໃນຮູບແບບຂອງຄຳສັບ BPF_W, ເຊິ່ງເປັນເລກໂທລະບົບທີ່ບັນຈຸຢູ່ໃນຄ່າຊົດເຊີຍຄົງທີ່ຂອງ BPF_ABS.

— BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, nr, 0, 1) — ປຽບທຽບເລກໂທລະບົບກັບຄ່າຂອງຕົວແປ nr. ຖ້າພວກມັນມີຄວາມເທົ່າທຽມກັນ, ໄປຫາຄໍາແນະນໍາຕໍ່ໄປແລະປິດການໂທລະບົບ, ຖ້າບໍ່ດັ່ງນັ້ນອະນຸຍາດໃຫ້ລະບົບການໂທດ້ວຍ SECOMP_RET_ALLOW.

- BPF_STMT(BPF_RET + BPF_K, SECOMP_RET_ERRNO | (error & SECOMP_RET_DATA)) - ຢຸດໂປຣແກມດ້ວຍ BPF_RET ແລະສົ່ງຜົນໃຫ້ເກີດຄວາມຜິດພາດ SECOMP_RET_ERRNO ກັບຕົວເລກຈາກຕົວແປ err.

- BPF_STMT(BPF_RET + BPF_K, SECOMP_RET_ALLOW) - ຢຸດໂຄງການດ້ວຍ BPF_RET ແລະອະນຸຍາດໃຫ້ດໍາເນີນການໂທຫາລະບົບໂດຍໃຊ້ SECOMP_RET_ALLOW.

SECOMP ແມ່ນ CBPF
ທ່ານອາດຈະສົງໄສວ່າເປັນຫຍັງບັນຊີລາຍຊື່ຄໍາແນະນໍາຖືກນໍາໃຊ້ແທນທີ່ຈະເປັນວັດຖຸ ELF ທີ່ລວບລວມຫຼືໂຄງການ C ທີ່ລວບລວມ JIT.

ມີສອງເຫດຜົນສໍາລັບການນີ້.

•ທໍາອິດ, Seccomp ໃຊ້ cBPF (BPF ຄລາສສິກ) ແລະບໍ່ແມ່ນ eBPF, ຊຶ່ງຫມາຍຄວາມວ່າ: ມັນບໍ່ມີທະບຽນ, ແຕ່ວ່າພຽງແຕ່ສະສົມເພື່ອເກັບຜົນສຸດທ້າຍຂອງການຄິດໄລ່, ດັ່ງທີ່ເຫັນໄດ້ໃນຕົວຢ່າງ.

•ອັນທີສອງ, Seccomp ຍອມຮັບຕົວຊີ້ໄປຫາ array ຂອງຄໍາແນະນໍາ BPF ໂດຍກົງແລະບໍ່ມີຫຍັງອີກ. ມະຫາພາກທີ່ພວກເຮົາໄດ້ໃຊ້ພຽງແຕ່ຊ່ວຍລະບຸຄໍາແນະນໍາເຫຼົ່ານີ້ໃນວິທີທີ່ເປັນມິດກັບໂປລແກລມ.

ຖ້າທ່ານຕ້ອງການຄວາມຊ່ວຍເຫຼືອເພີ່ມເຕີມເພື່ອເຂົ້າໃຈການປະກອບນີ້, ພິຈາລະນາ pseudocode ທີ່ເຮັດສິ່ງດຽວກັນ:

if (arch != AUDIT_ARCH_X86_64) {
    return SECCOMP_RET_ALLOW;
}
if (nr == __NR_write) {
    return SECCOMP_RET_ERRNO;
}
return SECCOMP_RET_ALLOW;

ຫຼັງຈາກກໍານົດລະຫັດການກັ່ນຕອງໃນໂຄງສ້າງ socket_filter, ທ່ານຈໍາເປັນຕ້ອງກໍານົດ sock_fprog ທີ່ມີລະຫັດແລະຄວາມຍາວຂອງການກັ່ນຕອງທີ່ຄິດໄລ່. ໂຄງສ້າງຂໍ້ມູນນີ້ແມ່ນຕ້ອງການເປັນການໂຕ້ຖຽງສໍາລັບການປະກາດຂະບວນການທີ່ຈະດໍາເນີນການຕໍ່ມາ:

struct sock_fprog prog = {
   .len = (unsigned short)(sizeof(filter) / sizeof(filter[0])),
   .filter = filter,
};

ມີພຽງແຕ່ສິ່ງດຽວທີ່ເຫຼືອໃຫ້ເຮັດໃນຟັງຊັນ install_filter - ໂຫລດໂປຼແກຼມຂອງມັນເອງ! ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໃຊ້ prctl, ເອົາ PR_SET_SECOMP ເປັນທາງເລືອກທີ່ຈະເຂົ້າສູ່ໂຫມດຄອມພິວເຕີ້ທີ່ປອດໄພ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາບອກໂຫມດການໂຫຼດການກັ່ນຕອງໂດຍໃຊ້ SECOMP_MODE_FILTER, ເຊິ່ງບັນຈຸຢູ່ໃນຕົວແປ prog ຂອງປະເພດ sock_fprog:

  if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog)) {
    perror("prctl(PR_SET_SECCOMP)");
    return 1;
  }
  return 0;
}

ສຸດທ້າຍ, ພວກເຮົາສາມາດໃຊ້ຟັງຊັນ install_filter ຂອງພວກເຮົາ, ແຕ່ກ່ອນນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງໃຊ້ prctl ເພື່ອກໍານົດ PR_SET_NO_NEW_PRIVS ສໍາລັບການປະຕິບັດໃນປະຈຸບັນແລະດັ່ງນັ້ນຈຶ່ງຫຼີກເວັ້ນສະຖານະການທີ່ຂະບວນການເດັກນ້ອຍໄດ້ຮັບສິດທິພິເສດຫຼາຍກ່ວາພໍ່ແມ່ຂອງເຂົາເຈົ້າ. ດ້ວຍນີ້, ພວກເຮົາສາມາດໂທຫາ prctl ຕໍ່ໄປນີ້ໃນຟັງຊັນ install_filter ໂດຍບໍ່ມີສິດທິຮາກ.

ຕອນນີ້ພວກເຮົາສາມາດໂທຫາຟັງຊັນ install_filter. ໃຫ້ບລັອກການຂຽນລະບົບທັງໝົດທີ່ກ່ຽວຂ້ອງກັບສະຖາປັດຕະຍະກຳ X86-64 ແລະພຽງແຕ່ໃຫ້ສິດທີ່ຂັດຂວາງຄວາມພະຍາຍາມທັງໝົດ. ຫຼັງຈາກການຕິດຕັ້ງຕົວກອງ, ພວກເຮົາສືບຕໍ່ດໍາເນີນການໂດຍໃຊ້ argument ທໍາອິດ:

int main(int argc, char const *argv[]) {
  if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
   perror("prctl(NO_NEW_PRIVS)");
   return 1;
  }
   install_filter(__NR_write, AUDIT_ARCH_X86_64, EPERM);
  return system(argv[1]);
 }

ໃຫ້ເລີ່ມຕົ້ນ. ເພື່ອລວບລວມໂປຼແກຼມຂອງພວກເຮົາພວກເຮົາສາມາດໃຊ້ clang ຫຼື gcc, ບໍ່ວ່າຈະເປັນພຽງແຕ່ລວບລວມໄຟລ໌ main.c ໂດຍບໍ່ມີທາງເລືອກພິເສດ:

clang main.c -o filter-write

ດັ່ງທີ່ບັນທຶກໄວ້, ພວກເຮົາໄດ້ບລັອກລາຍການທັງໝົດໃນໂປຣແກຣມແລ້ວ. ເພື່ອທົດສອບນີ້, ທ່ານຕ້ອງການໂຄງການທີ່ຜົນໄດ້ຮັບບາງສິ່ງບາງຢ່າງ - ls ເບິ່ງຄືວ່າເປັນຜູ້ສະຫມັກທີ່ດີ. ນີ້ແມ່ນວິທີທີ່ນາງມັກຈະປະຕິບັດ:

ls -la
total 36
drwxr-xr-x 2 fntlnz users 4096 Apr 28 21:09 .
drwxr-xr-x 4 fntlnz users 4096 Apr 26 13:01 ..
-rwxr-xr-x 1 fntlnz users 16800 Apr 28 21:09 filter-write
-rw-r--r-- 1 fntlnz users 19 Apr 28 21:09 .gitignore
-rw-r--r-- 1 fntlnz users 1282 Apr 28 21:08 main.c

ອັດສະຈັນ! ນີ້ແມ່ນສິ່ງທີ່ການນໍາໃຊ້ໂປຼແກຼມ wrapper ຂອງພວກເຮົາເບິ່ງຄືວ່າ: ພວກເຮົາພຽງແຕ່ຜ່ານໂຄງການທີ່ພວກເຮົາຕ້ອງການທົດສອບເປັນການໂຕ້ຖຽງທໍາອິດ:

./filter-write "ls -la"

ໃນ​ເວ​ລາ​ທີ່​ປະ​ຕິ​ບັດ​, ໂຄງ​ການ​ນີ້​ຜະ​ລິດ​ຜົນ​ຜະ​ລິດ​ເປົ່າ​ຫມົດ​. ແນວໃດກໍ່ຕາມ, ພວກເຮົາສາມາດໃຊ້ strace ເພື່ອເບິ່ງວ່າມີຫຍັງເກີດຂຶ້ນ:

strace -f ./filter-write "ls -la"

ຜົນໄດ້ຮັບຂອງການເຮັດວຽກແມ່ນສັ້ນລົງຢ່າງຫຼວງຫຼາຍ, ແຕ່ສ່ວນທີ່ສອດຄ້ອງກັນຂອງມັນສະແດງໃຫ້ເຫັນວ່າບັນທຶກຖືກບລັອກດ້ວຍຄວາມຜິດພາດ EPERM - ດຽວກັນທີ່ພວກເຮົາກໍານົດ. ນີ້ຫມາຍຄວາມວ່າໂປລແກລມບໍ່ອອກຫຍັງເພາະວ່າມັນບໍ່ສາມາດເຂົ້າຫາລະບົບການຂຽນການໂທ:

[pid 25099] write(2, "ls: ", 4) = -1 EPERM (Operation not permitted)
[pid 25099] write(2, "write error", 11) = -1 EPERM (Operation not permitted)
[pid 25099] write(2, "n", 1) = -1 EPERM (Operation not permitted)

ໃນປັດຈຸບັນທ່ານເຂົ້າໃຈວິທີການ Seccomp BPF ເຮັດວຽກແລະມີຄວາມຄິດທີ່ດີກ່ຽວກັບສິ່ງທີ່ທ່ານສາມາດເຮັດໄດ້ກັບມັນ. ແຕ່ເຈົ້າບໍ່ຢາກບັນລຸສິ່ງດຽວກັນກັບ eBPF ແທນ cBPF ເພື່ອໃຊ້ພະລັງງານຢ່າງເຕັມທີ່ບໍ?

ເມື່ອຄິດກ່ຽວກັບໂປແກມ eBPF, ຄົນສ່ວນໃຫຍ່ຄິດວ່າພວກເຂົາພຽງແຕ່ຂຽນແລະໂຫລດໃຫ້ເຂົາເຈົ້າມີສິດທິພິເສດຂອງຜູ້ບໍລິຫານ. ໃນຂະນະທີ່ຄໍາຖະແຫຼງນີ້ແມ່ນຄວາມຈິງໂດຍທົ່ວໄປ, kernel ປະຕິບັດຊຸດຂອງກົນໄກເພື່ອປົກປ້ອງວັດຖຸ eBPF ໃນລະດັບຕ່າງໆ. ກົນໄກເຫຼົ່ານີ້ເອີ້ນວ່າ BPF LSM traps.

BPF LSM ກັບດັກ

ເພື່ອໃຫ້ການຕິດຕາມເຫດການຂອງລະບົບແບບເອກະລາດສະຖາປັດຕະຍະກໍາ, LSM ປະຕິບັດແນວຄວາມຄິດຂອງໃສ່ກັບດັກ. ການໂທຫາ hook ແມ່ນທາງດ້ານວິຊາການຄ້າຍຄືກັນກັບການໂທຫາລະບົບ, ແຕ່ເປັນລະບົບເອກະລາດແລະປະສົມປະສານກັບໂຄງສ້າງພື້ນຖານ. LSM ສະຫນອງແນວຄວາມຄິດໃຫມ່ທີ່ຊັ້ນ abstraction ສາມາດຊ່ວຍຫຼີກເວັ້ນບັນຫາທີ່ພົບໃນເວລາທີ່ຈັດການກັບການໂທລະບົບກ່ຽວກັບສະຖາປັດຕະຍະກໍາທີ່ແຕກຕ່າງກັນ.

ໃນເວລາຂຽນ, kernel ມີເຈັດ hooks ທີ່ກ່ຽວຂ້ອງກັບໂຄງການ BPF, ແລະ SELinux ແມ່ນ LSM ທີ່ມີຕົວດຽວທີ່ປະຕິບັດພວກມັນ.

ລະຫັດແຫຼ່ງຂອງດັກແມ່ນຕັ້ງຢູ່ໃນ kernel tree ໃນໄຟລ໌ include/linux/security.h:

extern int security_bpf(int cmd, union bpf_attr *attr, unsigned int size);
extern int security_bpf_map(struct bpf_map *map, fmode_t fmode);
extern int security_bpf_prog(struct bpf_prog *prog);
extern int security_bpf_map_alloc(struct bpf_map *map);
extern void security_bpf_map_free(struct bpf_map *map);
extern int security_bpf_prog_alloc(struct bpf_prog_aux *aux);
extern void security_bpf_prog_free(struct bpf_prog_aux *aux);

ພວກເຂົາແຕ່ລະຈະຖືກເອີ້ນຢູ່ໃນຂັ້ນຕອນຕ່າງໆຂອງການປະຕິບັດ:

— security_bpf — ເຮັດ​ການ​ກວດ​ສອບ​ເບື້ອງ​ຕົ້ນ​ຂອງ​ການ​ໂທ​ລະ​ບົບ BPF ປະ​ຕິ​ບັດ​;

- security_bpf_map - ກວດເບິ່ງເວລາທີ່ kernel ສົ່ງຄືນໄຟລ໌ descriptor ສໍາລັບແຜນທີ່;

- security_bpf_prog - ກວດເບິ່ງເວລາທີ່ kernel ສົ່ງຄືນໄຟລ໌ descriptor ສໍາລັບໂຄງການ eBPF;

— security_bpf_map_alloc — ກວດ​ເບິ່ງ​ວ່າ​ພາກ​ສະ​ຫນາມ​ຄວາມ​ປອດ​ໄພ​ພາຍ​ໃນ​ແຜນ​ທີ່ BPF ແມ່ນ​ໄດ້​ເລີ່ມ​ຕົ້ນ​;

- security_bpf_map_free - ກວດເບິ່ງວ່າພາກສະຫນາມຄວາມປອດໄພໄດ້ຖືກອະນາໄມຢູ່ໃນແຜນທີ່ BPF;

— security_bpf_prog_alloc — ກວດເບິ່ງວ່າພາກສະຫນາມຄວາມປອດໄພໄດ້ຖືກເລີ່ມຕົ້ນພາຍໃນໂຄງການ BPF;

- security_bpf_prog_free - ກວດເບິ່ງວ່າພາກສະຫນາມຄວາມປອດໄພໄດ້ຖືກອະນາໄມພາຍໃນໂຄງການ BPF.

ໃນປັດຈຸບັນ, ເຫັນທັງຫມົດນີ້, ພວກເຮົາເຂົ້າໃຈ: ແນວຄວາມຄິດຂອງ LSM BPF interceptors ແມ່ນວ່າພວກເຂົາສາມາດສະຫນອງການປົກປ້ອງແຕ່ລະວັດຖຸ eBPF, ຮັບປະກັນວ່າພຽງແຕ່ຜູ້ທີ່ມີສິດທິທີ່ເຫມາະສົມສາມາດດໍາເນີນການກ່ຽວກັບບັດແລະໂຄງການ.

Summary

ຄວາມ​ປອດ​ໄພ​ບໍ່​ແມ່ນ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ທີ່​ທ່ານ​ສາ​ມາດ​ປະ​ຕິ​ບັດ​ໃນ​ວິ​ທີ​ການ​ຂະ​ຫນາດ​ດຽວ​ເຫມາະ​ສໍາ​ລັບ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະສາມາດປົກປ້ອງລະບົບຕ່າງໆໃນລະດັບຕ່າງໆແລະໃນທາງທີ່ແຕກຕ່າງກັນ. ເຊື່ອຫຼືບໍ່, ວິທີທີ່ດີທີ່ສຸດໃນການຮັກສາຄວາມປອດໄພຂອງລະບົບແມ່ນການຈັດລະບຽບລະດັບການປົກປ້ອງຈາກຕໍາແຫນ່ງທີ່ແຕກຕ່າງກັນ, ດັ່ງນັ້ນການຫຼຸດຜ່ອນຄວາມປອດໄພຂອງລະດັບຫນຶ່ງບໍ່ອະນຸຍາດໃຫ້ເຂົ້າເຖິງລະບົບທັງຫມົດ. ນັກພັດທະນາຫຼັກໄດ້ເຮັດວຽກທີ່ດີໃນການໃຫ້ພວກເຮົາຊຸດຊັ້ນຕ່າງໆ ແລະຈຸດສໍາຜັດຕ່າງໆ. ພວກເຮົາຫວັງວ່າພວກເຮົາໄດ້ໃຫ້ທ່ານເຂົ້າໃຈດີກ່ຽວກັບສິ່ງທີ່ຊັ້ນແມ່ນແລະວິທີການນໍາໃຊ້ໂປຼແກຼມ BPF ເພື່ອເຮັດວຽກກັບພວກມັນ.

ກ່ຽວກັບຜູ້ຂຽນ

David Calavera ແມ່ນ CTO ຢູ່ Netlify. ລາວໄດ້ເຮັດວຽກໃນການສະຫນັບສະຫນູນ Docker ແລະປະກອບສ່ວນເຂົ້າໃນການພັດທະນາເຄື່ອງມື Runc, Go ແລະ BCC, ເຊັ່ນດຽວກັນກັບໂຄງການແຫຼ່ງເປີດອື່ນໆ. ເປັນທີ່ຮູ້ຈັກສໍາລັບການເຮັດວຽກຂອງລາວກ່ຽວກັບໂຄງການ Docker ແລະການພັດທະນາລະບົບນິເວດ Docker plugin. David ມີຄວາມກະຕືລືລົ້ນຫຼາຍກ່ຽວກັບເສັ້ນສະແດງ flame ແລະສະເຫມີຊອກຫາການເພີ່ມປະສິດທິພາບການປະຕິບັດ.

Lorenzo Fontana ເຮັດວຽກຢູ່ໃນທີມງານແຫຼ່ງເປີດຢູ່ Sysdig, ບ່ອນທີ່ລາວສຸມໃສ່ຕົ້ນຕໍກ່ຽວກັບ Falco, ໂຄງການ Cloud Native Computing Foundation ທີ່ສະຫນອງຄວາມປອດໄພຂອງ container runtime ແລະການກວດສອບຄວາມຜິດປົກກະຕິຜ່ານໂມດູນແກ່ນແລະ eBPF. ລາວມີຄວາມກະຕືລືລົ້ນກ່ຽວກັບລະບົບແຈກຢາຍ, ຊອບແວທີ່ກໍານົດເຄືອຂ່າຍ, ແກ່ນ Linux, ແລະການວິເຄາະປະສິດທິພາບ.

» ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບປຶ້ມສາມາດເຂົ້າໄປເບິ່ງໄດ້ທີ່ ເວັບໄຊທ໌ຂອງຜູ້ເຜີຍແຜ່
» ຕາຕະລາງເນື້ອຫາ
» ບົດຄັດຫຍໍ້

ສໍາລັບ Khabrozhiteley ສ່ວນລົດ 25% ການນໍາໃຊ້ຄູປອງ - Linux

ພາຍຫຼັງການຊໍາລະສະບັບເຈ້ຍຂອງປຶ້ມ, ປຶ້ມອີເລັກໂທຣນິກຈະຖືກສົ່ງໄປທາງອີເມລ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com