"लिनक्स निगरानी को लागी BPF" बुक गर्नुहोस्

नमस्ते खबरबासीहरु ! BPF भर्चुअल मेसिन लिनक्स कर्नेल को सबैभन्दा महत्त्वपूर्ण घटक मध्ये एक हो। यसको उचित प्रयोगले प्रणाली इन्जिनियरहरूलाई त्रुटिहरू फेला पार्न र सबैभन्दा जटिल समस्याहरू पनि समाधान गर्न अनुमति दिनेछ। तपाईंले कर्नेलको व्यवहार अनुगमन र परिमार्जन गर्ने कार्यक्रमहरू कसरी लेख्ने, कर्नेलमा घटनाहरू निगरानी गर्न कोडहरू कसरी सुरक्षित रूपमा कार्यान्वयन गर्ने, र धेरै कुराहरू सिक्नुहुनेछ। David Calavera र Lorenzo Fontana ले तपाईंलाई BPF को शक्ति अनलक गर्न मद्दत गर्नेछ। कार्यसम्पादन अप्टिमाइजेसन, नेटवर्किङ, सुरक्षाको आफ्नो ज्ञान विस्तार गर्नुहोस्। - लिनक्स कर्नेलको व्यवहार अनुगमन र परिमार्जन गर्न BPF प्रयोग गर्नुहोस्। - कर्नेल पुन: कम्पाइल वा प्रणाली रिबुट नगरी कर्नेल घटनाहरू सुरक्षित रूपमा निगरानी गर्न कोड इन्जेक्ट गर्नुहोस्। - C, Go वा Python मा सुविधाजनक कोड उदाहरणहरू प्रयोग गर्नुहोस्। - BPF कार्यक्रम जीवनचक्रको स्वामित्व लिएर नियन्त्रण लिनुहोस्।

लिनक्स कर्नेल सुरक्षा, यसको सुविधाहरू र Seccomp

BPF ले स्थिरता, सुरक्षा, वा गति त्याग नगरी कर्नेल विस्तार गर्न एक शक्तिशाली तरिका प्रदान गर्दछ। यस कारणले गर्दा, कर्नेल विकासकर्ताहरूले Seccomp मा BPF कार्यक्रमहरू द्वारा समर्थित Seccomp फिल्टरहरू, जसलाई Seccomp BPF पनि भनिन्छ, लागू गरेर प्रक्रिया अलगाव सुधार गर्न यसको बहुमुखी प्रतिभा प्रयोग गर्नु राम्रो विचार हो भन्ने सोचेका थिए। यस अध्यायमा हामी Seccomp के हो र यसलाई कसरी प्रयोग गरिन्छ भनेर व्याख्या गर्नेछौं। त्यसपछि तपाईले BPF प्रोग्रामहरू प्रयोग गरेर Seccomp फिल्टरहरू कसरी लेख्ने भनेर सिक्नुहुनेछ। त्यस पछि, हामी बिल्ट-इन BPF हुकहरू हेर्नेछौं जुन लिनक्स सुरक्षा मोड्युलहरूको लागि कर्नेलमा समावेश छ।

लिनक्स सेक्युरिटी मोड्युल (LSM) एक ढाँचा हो जसले कार्यहरूको सेट प्रदान गर्दछ जुन विभिन्न सुरक्षा मोडेलहरूलाई मानकीकृत रूपमा लागू गर्न प्रयोग गर्न सकिन्छ। LSM सिधै कर्नेल स्रोत रूखमा प्रयोग गर्न सकिन्छ, जस्तै Apparmor, SELinux र Tomoyo।

लिनक्सको क्षमताहरू छलफल गरेर सुरु गरौं।

विशेषताहरू

लिनक्सको क्षमताहरूको सार यो हो कि तपाइँले एक निश्चित कार्य गर्नको लागि एक विशेष प्रक्रिया अनुमति प्रदान गर्न आवश्यक छ, तर त्यस उद्देश्यको लागि suid प्रयोग नगरी, वा अन्यथा प्रक्रियालाई विशेषाधिकार बनाउनुहोस्, आक्रमणको सम्भावना कम गर्दै र प्रक्रियालाई निश्चित कार्यहरू गर्न अनुमति दिनुहोस्। उदाहरणका लागि, यदि तपाइँको अनुप्रयोगलाई विशेषाधिकार प्राप्त पोर्ट खोल्न आवश्यक छ भने, 80 भन्नुहोस्, प्रक्रियालाई रूटको रूपमा चलाउनुको सट्टा, तपाइँ यसलाई CAP_NET_BIND_SERVICE क्षमता दिन सक्नुहुन्छ।

main.go नामक Go कार्यक्रमलाई विचार गर्नुहोस्:

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

यो कार्यक्रम पोर्ट 80 मा HTTP सर्भर सेवा गर्दछ (यो एक विशेषाधिकार प्राप्त पोर्ट हो)। सामान्यतया हामी यसलाई संकलन पछि तुरुन्तै चलाउँछौं:

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

यद्यपि, हामीले रूट विशेषाधिकारहरू प्रदान नगरेको हुनाले, यो कोडले पोर्ट बाइन्डिङ गर्दा त्रुटि फ्याँक्नेछ:

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

capsh (शेल प्रबन्धक) एक उपकरण हो जसले क्षमताहरूको एक निश्चित सेटको साथ शेल चलाउँछ।

यस अवस्थामा, पहिले नै उल्लेख गरिएझैं, पूर्ण रूट अधिकारहरू प्रदान गर्नुको सट्टा, तपाईंले कार्यक्रममा पहिले नै रहेका सबै कुराहरू सहित cap_net_bind_service क्षमता प्रदान गरेर विशेषाधिकार प्राप्त पोर्ट बाइन्डिङ सक्षम गर्न सक्नुहुन्छ। यो गर्नको लागि, हामी हाम्रो कार्यक्रम क्यापशमा संलग्न गर्न सक्छौं:

# 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' - हामीले प्रयोगकर्ता परिवर्तन गर्न आवश्यक भएकोले (हामी रूटको रूपमा चलाउन चाहँदैनौं), हामी cap_net_bind_service निर्दिष्ट गर्नेछौं र वास्तवमा प्रयोगकर्ता आईडी परिवर्तन गर्ने क्षमता root to nobody, अर्थात् cap_setuid र cap_setgid।
• —keep=1 — हामी रूट खाताबाट स्विच गर्दा स्थापित क्षमताहरू राख्न चाहन्छौं।
• —user=“कुनै पनि” — कार्यक्रम चलाउने अन्तिम प्रयोगकर्ता कोही पनि हुनेछैन।
• —addamb=cap_net_bind_service — रूट मोडबाट स्विच गरेपछि सम्बन्धित क्षमताहरूको क्लियरिङ सेट गर्नुहोस्।
• - -c "./capabilities" - कार्यक्रम चलाउनुहोस्।

लिङ्क गरिएका क्षमताहरू विशेष प्रकारका क्षमताहरू हुन् जुन बाल कार्यक्रमहरूद्वारा विरासतमा प्राप्त हुन्छन् जब हालको कार्यक्रमले तिनीहरूलाई execve() प्रयोग गरेर कार्यान्वयन गर्दछ। केवल क्षमताहरू जुन सम्बन्धित हुन अनुमति दिइएको छ, वा अन्य शब्दहरूमा, वातावरण क्षमताहरूको रूपमा, विरासतमा प्राप्त गर्न सकिन्छ।

--caps विकल्पमा क्षमता निर्दिष्ट गरेपछि तपाईं +eip को अर्थ के हो भनेर सोचिरहनुभएको छ। यी झण्डाहरू क्षमता निर्धारण गर्न प्रयोग गरिन्छ:

- सक्रिय हुनुपर्छ (p);

-उपयोगको लागि उपलब्ध (ई);

-बाल प्रक्रिया (i) द्वारा वंशानुगत हुन सक्छ।

किनकि हामी cap_net_bind_service प्रयोग गर्न चाहन्छौं, हामीले यो ई फ्ल्यागको साथ गर्नुपर्छ। त्यसपछि हामी कमाण्डमा शेल सुरु गर्नेछौं। यसले क्षमताहरू बाइनरी चलाउनेछ र हामीले यसलाई i झण्डाको साथ चिन्ह लगाउन आवश्यक छ। अन्तमा, हामी सुविधा सक्षम गर्न चाहन्छौं (हामीले UID परिवर्तन नगरीकन यो गर्यौं) p. यो cap_net_bind_service+eip जस्तो देखिन्छ।

तपाईं ss प्रयोग गरेर परिणाम जाँच गर्न सक्नुहुन्छ। पृष्ठमा फिट गर्नको लागि आउटपुटलाई थोरै छोटो गरौं, तर यसले ० बाहेक अन्य सम्बन्धित पोर्ट र प्रयोगकर्ता आईडी देखाउनेछ, यस अवस्थामा 0:

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

यस उदाहरणमा हामीले क्यापस प्रयोग गर्यौं, तर तपाईले libcap प्रयोग गरेर शेल लेख्न सक्नुहुन्छ। थप जानकारीको लागि, man 3 libcap हेर्नुहोस्।

प्रोग्रामहरू लेख्दा, प्राय: विकासकर्तालाई कार्यक्रमलाई चल्ने समयमा चाहिने सबै सुविधाहरू पहिले नै थाहा हुँदैन। यसबाहेक, यी सुविधाहरू नयाँ संस्करणहरूमा परिवर्तन हुन सक्छ।

हाम्रो कार्यक्रमको क्षमताहरू राम्रोसँग बुझ्नको लागि, हामी BCC सक्षम उपकरण लिन सक्छौं, जसले cap_capable कर्नेल प्रकार्यको लागि kprobe सेट गर्दछ:

/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

हामीले cap_capable कर्नेल प्रकार्यमा एक-लाइनर kprobe को साथ bpftrace प्रयोग गरेर समान कुरा हासिल गर्न सक्छौं:

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

यदि हाम्रो कार्यक्रमको क्षमताहरू केप्रोब पछि सक्षम पारिएमा यसले निम्न जस्तै आउटपुट गर्नेछ:

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 मा रुचि राखेका छौं, यसलाई फाइलमा समावेश/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">

रनसी वा डकर जस्ता कन्टेनरहरूको लागि रनटाइममा क्षमताहरू सक्रिय हुन्छन् तिनीहरूलाई विशेषाधिकाररहित मोडमा चलाउन अनुमति दिनको लागि, तर उनीहरूलाई धेरै अनुप्रयोगहरू चलाउन आवश्यक क्षमताहरू मात्र अनुमति दिइन्छ। जब एप्लिकेसनलाई निश्चित क्षमताहरू चाहिन्छ, डकरले तिनीहरूलाई --cap-add प्रयोग गरेर प्रदान गर्न सक्छ:

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

यो आदेशले कन्टेनरलाई CAP_NET_ADMIN क्षमता दिनेछ, यसले dummy0 इन्टरफेस थप्न नेटवर्क लिङ्क कन्फिगर गर्न अनुमति दिन्छ।

अर्को खण्डले फिल्टर गर्ने जस्ता सुविधाहरू कसरी प्रयोग गर्ने भनेर देखाउँछ, तर हामीलाई हाम्रो आफ्नै फिल्टरहरू प्रोग्राम्याटिक रूपमा कार्यान्वयन गर्न अनुमति दिने फरक प्रविधि प्रयोग गरेर।

सेकम्प

Seccomp Secure Computing को लागि खडा छ र Linux कर्नेलमा लागू गरिएको सुरक्षा तह हो जसले विकासकर्ताहरूलाई निश्चित प्रणाली कलहरू फिल्टर गर्न अनुमति दिन्छ। यद्यपि Seccomp लिनक्ससँग क्षमताहरूमा तुलनात्मक छ, यसको निश्चित प्रणाली कलहरू व्यवस्थापन गर्ने क्षमताले तिनीहरूको तुलनामा यसलाई धेरै लचिलो बनाउँछ।

Seccomp र Linux सुविधाहरू पारस्परिक रूपमा अनन्य छैनन् र प्रायः दुवै दृष्टिकोणबाट लाभ उठाउन सँगै प्रयोग गरिन्छ। उदाहरणका लागि, तपाइँ प्रक्रियालाई CAP_NET_ADMIN क्षमता दिन चाहन सक्नुहुन्छ तर यसलाई सकेट जडानहरू स्वीकार गर्न अनुमति दिनुहुन्न, स्वीकार र स्वीकार 4 प्रणाली कलहरू रोक्दै।

Seccomp फिल्टरिङ विधि SECOMP_MODE_FILTER मोडमा काम गर्ने BPF फिल्टरहरूमा आधारित छ, र प्रणाली कल फिल्टरिङ प्याकेटहरूको लागि जस्तै गरी गरिन्छ।

Seccomp फिल्टरहरू PR_SET_SECCOMP सञ्चालन मार्फत prctl प्रयोग गरेर लोड हुन्छन्। यी फिल्टरहरूले BPF कार्यक्रमको रूप लिन्छन् जुन प्रत्येक Seccomp प्याकेटको लागि seccomp_data संरचनाद्वारा प्रतिनिधित्व गरिन्छ। यो संरचनाले सन्दर्भ संरचना समावेश गर्दछ, प्रणाली कलको समयमा प्रोसेसर निर्देशनहरूको लागि सूचक, र अधिकतम छवटा प्रणाली कल तर्कहरू, uint64 को रूपमा व्यक्त गरिन्छ।

यो linux/seccomp.h फाइलमा कर्नेल स्रोत कोडबाट seccomp_data संरचना जस्तो देखिन्छ:

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

तपाईले यस संरचनाबाट देख्न सक्नुहुन्छ, हामी प्रणाली कल, यसको तर्क, वा दुवैको संयोजनद्वारा फिल्टर गर्न सक्छौं।

प्रत्येक Seccomp प्याकेट प्राप्त गरेपछि, फिल्टरले अन्तिम निर्णय गर्न र कर्नेललाई अर्को के गर्ने भनेर प्रशोधन गर्नुपर्दछ। अन्तिम निर्णय फिर्ता मान (स्थिति कोड) मध्ये एक द्वारा व्यक्त गरिएको छ।

- SECOMP_RET_KILL_PROCESS - यस कारण कार्यान्वयन नगरिएको प्रणाली कल फिल्टर गरेपछि तुरुन्तै सम्पूर्ण प्रक्रियालाई मार्छ।

- SECOMP_RET_KILL_THREAD - यस कारण कार्यान्वयन नभएको प्रणाली कल फिल्टर गरेपछि तुरुन्तै हालको थ्रेड बन्द गर्दछ।

— SECOMP_RET_KILL — SECOMP_RET_KILL_THREAD को लागि उपनाम, पछाडि अनुकूलताको लागि छोडियो।

- SECOMP_RET_TRAP - प्रणाली कल निषेधित छ, र SIGSYS (खराब प्रणाली कल) सिग्नल यसलाई कल गर्ने कार्यमा पठाइन्छ।

- SECOMP_RET_ERRNO - प्रणाली कल कार्यान्वयन गरिएको छैन, र SECOMP_RET_DATA फिल्टर रिटर्न मानको अंश प्रयोगकर्ता स्पेसलाई त्रुटि मानको रूपमा पठाइन्छ। त्रुटिको कारणमा निर्भर गर्दै, फरक त्रुटि मानहरू फर्काइन्छ। अर्को खण्डमा त्रुटि नम्बरहरूको सूची प्रदान गरिएको छ।

- SECOMP_RET_TRACE - प्रयोग गरेर ptrace ट्रेसरलाई सूचित गर्न प्रयोग गरिन्छ - PTRACE_O_TRACESECCOMP त्यो प्रक्रिया हेर्न र नियन्त्रण गर्न प्रणाली कल निष्पादित हुँदा अवरोध गर्न। यदि ट्रेसर जडान गरिएको छैन भने, त्रुटि फर्काइन्छ, त्रुटि -ENOSYS मा सेट गरिएको छ, र प्रणाली कल कार्यान्वयन गरिएको छैन।

- SECOMP_RET_LOG - प्रणाली कल समाधान भयो र लग गरियो।

- SECOMP_RET_ALLOW - प्रणाली कल मात्र अनुमति छ।

ptrace ट्रेस भनिने प्रक्रियामा ट्रेसिङ मेकानिजमहरू लागू गर्न प्रणाली कल हो, प्रक्रियाको कार्यान्वयनलाई निगरानी र नियन्त्रण गर्ने क्षमताको साथ। ट्रेस कार्यक्रमले प्रभावकारी रूपमा कार्यान्वयनलाई प्रभाव पार्न सक्छ र ट्रेसीको मेमोरी दर्ताहरू परिमार्जन गर्न सक्छ। Seccomp सन्दर्भमा, ptrace प्रयोग गरिन्छ जब SECOMP_RET_TRACE स्थिति कोड द्वारा ट्रिगर गरिन्छ, त्यसैले ट्रेसरले प्रणाली कललाई कार्यान्वयन गर्न र आफ्नै तर्क लागू गर्नबाट रोक्न सक्छ।

Seccomp त्रुटिहरू

समय-समयमा, Seccomp सँग काम गर्दा, तपाईंले विभिन्न त्रुटिहरू सामना गर्नुहुनेछ, जुन SECOMP_RET_ERRNO प्रकारको फिर्ती मानद्वारा पहिचान गरिन्छ। त्रुटि रिपोर्ट गर्न, seccomp प्रणाली कल 1 को सट्टा -0 फर्काउनेछ।

निम्न त्रुटिहरू सम्भव छन्:

- EACCESS - कलरलाई प्रणाली कल गर्न अनुमति छैन। यो सामान्यतया हुन्छ किनभने यसमा CAP_SYS_ADMIN विशेषाधिकारहरू छैनन् वा prctl प्रयोग गरेर no_new_privs सेट गरिएको छैन (हामी यस बारे पछि कुरा गर्नेछौं);

— EFAULT — पारित तर्कहरू (seccomp_data संरचनामा args) सँग वैध ठेगाना हुँदैन;

- EINVAL - यहाँ चार कारण हुन सक्छ:

- अनुरोध गरिएको अपरेशन अज्ञात छ वा हालको कन्फिगरेसनमा कर्नेल द्वारा समर्थित छैन;

- निर्दिष्ट झण्डाहरू अनुरोध गरिएको सञ्चालनको लागि मान्य छैनन्;

-सञ्चालनले BPF_ABS समावेश गर्दछ, तर निर्दिष्ट अफसेटमा समस्याहरू छन्, जुन seccomp_data संरचनाको आकार भन्दा बढी हुन सक्छ;

-फिल्टरमा पठाइएका निर्देशनहरूको संख्या अधिकतम भन्दा बढी छ;

— ENOMEM — कार्यक्रम कार्यान्वयन गर्न पर्याप्त मेमोरी छैन;

- EOPNOTSUPP - अपरेसनले संकेत गर्‍यो कि SECOMP_GET_ACTION_AVAIL सँग कार्य उपलब्ध थियो, तर कर्नेलले तर्कहरूमा फिर्ताहरूलाई समर्थन गर्दैन;

— ESRCH — अर्को स्ट्रिम सिङ्क्रोनाइज गर्दा समस्या आयो;

- ENOSYS - SECOMP_RET_TRACE कार्यमा संलग्न कुनै ट्रेसर छैन।

prctl एक प्रणाली कल हो जसले प्रयोगकर्ता-स्पेस प्रोग्रामलाई प्रक्रियाको विशिष्ट पक्षहरू हेरफेर (सेट र प्राप्त) गर्न अनुमति दिन्छ, जस्तै बाइट एन्डियननेस, थ्रेड नामहरू, सुरक्षित गणना मोड (सेकम्प), विशेषाधिकारहरू, परफ घटनाहरू, आदि।

Seccomp तपाईंलाई स्यान्डबक्स प्रविधि जस्तो लाग्न सक्छ, तर यो होइन। Seccomp एक उपयोगिता हो जसले प्रयोगकर्ताहरूलाई स्यान्डबक्स मेकानिज्म विकास गर्न अनुमति दिन्छ। अब हेरौं कसरी प्रयोगकर्ता अन्तरक्रिया कार्यक्रम Seccomp प्रणाली कल द्वारा सीधा बोलाइएको फिल्टर प्रयोग गरेर सिर्जना गरिन्छ।

BPF Seccomp फिल्टर उदाहरण

यहाँ हामी पहिले छलफल गरिएका दुई कार्यहरू कसरी संयोजन गर्ने भनेर देखाउनेछौं, अर्थात्:

— हामी एक Seccomp BPF कार्यक्रम लेख्नेछौं, जुन निर्णयहरूको आधारमा फरक फिर्ता कोडहरूको साथ फिल्टरको रूपमा प्रयोग गरिनेछ;

prctl प्रयोग गरेर फिल्टर लोड गर्नुहोस्।

पहिले तपाईलाई मानक पुस्तकालय र लिनक्स कर्नेलबाट हेडरहरू चाहिन्छ:

#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>

यो उदाहरण प्रयास गर्नु अघि, हामीले यो सुनिश्चित गर्नुपर्छ कि कर्नेल CONFIG_SECCOMP र CONFIG_SECCOMP_FILTER y मा सेट गरिएको छ। काम गर्ने मेसिनमा तपाईले यसलाई यसरी जाँच गर्न सक्नुहुन्छ:

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

कोडको बाँकी दुई-भाग install_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),
  };

निर्देशनहरू linux/filter.h फाइलमा परिभाषित BPF_STMT र BPF_JUMP म्याक्रोहरू प्रयोग गरेर सेट गरिएका छन्।
निर्देशनहरू मार्फत जाऔं।

- 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 एक्युमुलेटर स्थिरतामा आर्किटेक्चर मान आर्क बराबर छ। यदि त्यसो हो भने, अर्को निर्देशनमा अफसेट ० मा जम्प गर्नुहोस्, अन्यथा आर्च मिल्दैन किनभने त्रुटि फ्याँक्न अफसेट 0 (यस अवस्थामा) मा जम्प गर्नुहोस्।

- 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 | (त्रुटि र SECCOMP_RET_DATA)) - BPF_RET सँग कार्यक्रम समाप्त गर्दछ र परिणाम स्वरूप त्रुटि चरबाट संख्याको साथ त्रुटि SECOMP_RET_ERRNO उत्पन्न गर्दछ।

- BPF_STMT(BPF_RET + BPF_K, SECOMP_RET_ALLOW) - BPF_RET को साथ कार्यक्रम समाप्त गर्दछ र SECCOMP_RET_ALLOW प्रयोग गरेर प्रणाली कललाई कार्यान्वयन गर्न अनुमति दिन्छ।

SECOMP CBPF हो
तपाइँ सोचिरहनु भएको हुन सक्छ किन निर्देशनहरूको सूची कम्पाइल गरिएको ELF वस्तु वा JIT कम्पाइल गरिएको C कार्यक्रमको सट्टा प्रयोग गरिन्छ।

यसका दुईवटा कारण छन्।

• सबैभन्दा पहिले, Seccomp ले cBPF (क्लासिक BPF) प्रयोग गर्दछ eBPF होइन, जसको मतलब: यसमा कुनै दर्ता छैन, तर अन्तिम गणना परिणाम भण्डारण गर्नको लागि मात्र एक संचयक, उदाहरणमा देख्न सकिन्छ।

• दोस्रो, Seccomp ले BPF निर्देशनहरूको एर्रेमा सिधै सूचक स्वीकार गर्छ र अरू केही होइन। हामीले प्रयोग गरेका म्याक्रोहरूले यी निर्देशनहरूलाई प्रोग्रामर-अनुकूल तरिकामा निर्दिष्ट गर्न मद्दत गर्छ।

यदि तपाइँलाई यो सम्मेलन बुझ्न थप मद्दत चाहिन्छ भने, स्यूडोकोडलाई विचार गर्नुहोस् जसले समान काम गर्दछ:

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 प्रकार्यमा गर्नको लागि एउटा मात्र कुरा बाँकी छ - कार्यक्रम आफै लोड गर्नुहोस्! यसका लागि, हामी सुरक्षित कम्प्युटिङ मोडमा प्रवेश गर्ने विकल्पको रूपमा PR_SET_SECCOMP लिँदै prctl प्रयोग गर्छौं। त्यसपछि हामी मोडलाई SECOMP_MODE_FILTER प्रयोग गरेर फिल्टर लोड गर्न भन्छौं, जुन प्रकार sock_fprog को प्रोग चरमा समावेश छ:

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

अन्तमा, हामी हाम्रो install_filter प्रकार्य प्रयोग गर्न सक्छौं, तर त्यो भन्दा पहिले हामीले हालको कार्यान्वयनको लागि PR_SET_NO_NEW_PRIVS सेट गर्न prctl प्रयोग गर्न आवश्यक छ र यसरी बच्चा प्रक्रियाहरूले आफ्ना अभिभावकहरू भन्दा बढी विशेषाधिकारहरू प्राप्त गर्ने अवस्थाबाट बच्न आवश्यक छ। यसबाट, हामी रूट अधिकार बिना install_filter प्रकार्यमा निम्न prctl कलहरू गर्न सक्छौं।

अब हामी install_filter प्रकार्य कल गर्न सक्छौं। X86-64 आर्किटेक्चरसँग सम्बन्धित सबै लेखन प्रणाली कलहरू ब्लक गरौं र सबै प्रयासहरूलाई रोक लगाउने अनुमति दिनुहोस्। फिल्टर स्थापना गरेपछि, हामी पहिलो तर्क प्रयोग गरेर कार्यान्वयन जारी राख्छौं:

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]);
 }

सुरु गरौं। हाम्रो कार्यक्रम कम्पाइल गर्नको लागि हामी क्लाङ्ग वा 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

अद्भुत! हाम्रो र्‍यापर प्रोग्राम प्रयोग गरेर के जस्तो देखिन्छ यहाँ छ: हामीले पहिलो तर्कको रूपमा परीक्षण गर्न चाहेको कार्यक्रमलाई मात्र पास गर्छौं:

./filter-write "ls -la"

जब कार्यान्वयन हुन्छ, यो कार्यक्रमले पूर्ण रूपमा खाली आउटपुट उत्पादन गर्दछ। यद्यपि, हामी के भइरहेको छ भनेर हेर्न स्ट्रेस प्रयोग गर्न सक्छौं:

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)

अब तपाईंले सेकम्प बीपीएफले कसरी काम गर्छ भनी बुझ्नुभयो र तपाईं यसको साथ के गर्न सक्नुहुन्छ भन्ने राम्रो विचार छ। तर के तपाइँ cBPF को सट्टा eBPF सँग यसको पूर्ण शक्ति प्रयोग गर्नको लागि समान चीज प्राप्त गर्न चाहनुहुन्न?

eBPF कार्यक्रमहरूको बारेमा सोच्दा, धेरै मानिसहरूले सोच्छन् कि उनीहरूले तिनीहरूलाई मात्र लेख्छन् र तिनीहरूलाई प्रशासक विशेषाधिकारहरूसँग लोड गर्छन्। यद्यपि यो कथन सामान्यतया सत्य हो, कर्नेलले विभिन्न स्तरहरूमा eBPF वस्तुहरू सुरक्षित गर्न संयन्त्रहरूको सेट लागू गर्दछ। यी संयन्त्रहरूलाई BPF LSM जाल भनिन्छ।

BPF LSM जाल

प्रणाली घटनाहरूको वास्तुकला-स्वतन्त्र निगरानी प्रदान गर्न, LSM ले जालको अवधारणा लागू गर्दछ। हुक कल प्राविधिक रूपमा प्रणाली कलसँग मिल्दोजुल्दो छ, तर प्रणाली स्वतन्त्र र पूर्वाधारसँग एकीकृत छ। LSM ले एउटा नयाँ अवधारणा प्रदान गर्दछ जसमा एब्स्ट्र्याकसन लेयरले विभिन्न आर्किटेक्चरहरूमा प्रणाली कलहरूसँग व्यवहार गर्दा सामना गर्ने समस्याहरूबाट बच्न मद्दत गर्न सक्छ।

लेख्ने समयमा, कर्नेलसँग BPF कार्यक्रमहरूसँग सम्बन्धित सातवटा हुकहरू छन्, र SELinux मात्र निर्मित LSM हो जसले तिनीहरूलाई लागू गर्दछ।

जालहरूको लागि स्रोत कोड फाइलको कर्नेल रूखमा अवस्थित छ 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 - जाँच गर्दछ जब कर्नेलले नक्साको लागि फाइल वर्णनकर्ता फर्काउँछ;

- security_bpf_prog - जाँच गर्दछ जब कर्नेलले eBPF कार्यक्रमको लागि फाइल वर्णनकर्ता फर्काउँछ;

— security_bpf_map_alloc — BPF नक्सा भित्रको सुरक्षा क्षेत्र प्रारम्भ गरिएको छ कि छैन भनेर जाँच गर्दछ;

- security_bpf_map_free - BPF नक्सा भित्र सुरक्षा क्षेत्र खाली गरिएको छ कि छैन भनेर जाँच गर्दछ;

— security_bpf_prog_alloc — BPF कार्यक्रमहरू भित्र सुरक्षा क्षेत्र प्रारम्भ गरिएको छ कि छैन जाँच गर्दछ;

- security_bpf_prog_free - BPF कार्यक्रमहरू भित्र सुरक्षा क्षेत्र खाली गरिएको छ कि छैन भनेर जाँच गर्दछ।

अब, यी सबै देखेर, हामी बुझ्छौं: LSM BPF इन्टरसेप्टरहरूको पछाडिको विचार यो हो कि तिनीहरूले प्रत्येक eBPF वस्तुलाई सुरक्षा प्रदान गर्न सक्छन्, यो सुनिश्चित गर्दै कि उपयुक्त विशेषाधिकार भएकाहरूले मात्र कार्ड र कार्यक्रमहरूमा सञ्चालन गर्न सक्छन्।

सारांश

सुरक्षा भनेको तपाईंले सुरक्षा गर्न चाहनुहुने सबै कुराको लागि एक-साइज-फिट-सबै तरिकामा लागू गर्न सक्ने कुरा होइन। विभिन्न स्तरमा र विभिन्न तरिकामा प्रणालीहरू सुरक्षित गर्न सक्षम हुनु महत्त्वपूर्ण छ। विश्वास गर्नुहोस् वा नगर्नुहोस्, प्रणाली सुरक्षित गर्ने उत्तम तरिका भनेको विभिन्न स्थानहरूबाट सुरक्षाको विभिन्न स्तरहरू व्यवस्थित गर्नु हो, ताकि एक तहको सुरक्षालाई कम गर्दा सम्पूर्ण प्रणालीमा पहुँचलाई अनुमति दिँदैन। मुख्य विकासकर्ताहरूले हामीलाई विभिन्न तह र टचपोइन्टहरूको सेट दिएर उत्कृष्ट काम गरेका छन्। हामी आशा गर्दछौं कि हामीले तपाईंलाई तहहरू के हुन् र तिनीहरूसँग काम गर्न BPF कार्यक्रमहरू कसरी प्रयोग गर्ने भन्ने बारे राम्रोसँग बुझेका छौं।

लेखकहरूको बारेमा

डेभिड कालावेरा Netlify मा CTO हुनुहुन्छ। उहाँले डकर समर्थनमा काम गर्नुभयो र Runc, Go र BCC उपकरणहरू, साथै अन्य खुला स्रोत परियोजनाहरूको विकासमा योगदान गर्नुभयो। डकर परियोजनाहरू र डकर प्लगइन इकोसिस्टमको विकासमा उनको कामको लागि परिचित। डेभिड ज्वाला ग्राफहरूको बारेमा धेरै भावुक छ र सधैं प्रदर्शन अनुकूलन गर्न खोजिरहेको छ।

लोरेन्जो फन्टाना Sysdig मा खुला स्रोत टोलीमा काम गर्दछ, जहाँ उहाँ मुख्य रूपमा Falco मा केन्द्रित हुनुहुन्छ, एक क्लाउड नेटिभ कम्प्युटिङ फाउन्डेशन परियोजना जसले कन्टेनर रनटाइम सुरक्षा र कर्नेल मोड्युल र eBPF मार्फत विसंगति पत्ता लगाउने सुविधा प्रदान गर्दछ। उहाँ वितरित प्रणालीहरू, सफ्टवेयर परिभाषित नेटवर्किङ, लिनक्स कर्नेल, र प्रदर्शन विश्लेषणको बारेमा भावुक हुनुहुन्छ।

» पुस्तकको बारेमा थप विवरणहरू यहाँ पाउन सकिन्छ प्रकाशकको ​​वेबसाइट
» सामग्रीको तालिका
» अंश

Khabrozhiteley को लागि कुपन प्रयोग गरेर 25% छुट - लिनक्स

पुस्तकको पेपर संस्करणको भुक्तानी गरेपछि, एक इलेक्ट्रोनिक पुस्तक इ-मेल मार्फत पठाइनेछ।

स्रोत: www.habr.com