"લિનક્સ મોનિટરિંગ માટે BPF" બુક કરો

હેલો, ખાબરોના રહેવાસીઓ! BPF વર્ચ્યુઅલ મશીન એ Linux કર્નલના સૌથી મહત્વપૂર્ણ ઘટકોમાંનું એક છે. તેનો યોગ્ય ઉપયોગ સિસ્ટમ એન્જિનિયરોને ખામીઓ શોધવા અને સૌથી જટિલ સમસ્યાઓને ઉકેલવા માટે પરવાનગી આપશે. તમે કર્નલની વર્તણૂકને મોનિટર અને સંશોધિત કરતા પ્રોગ્રામ્સ કેવી રીતે લખવા તે શીખી શકશો, કર્નલમાં ઇવેન્ટ્સને મોનિટર કરવા માટે કોડને સુરક્ષિત રીતે કેવી રીતે અમલમાં મૂકવો, અને ઘણું બધું. David Calavera અને Lorenzo Fontana તમને BPF ની શક્તિને અનલૉક કરવામાં મદદ કરશે. પરફોર્મન્સ ઓપ્ટિમાઇઝેશન, નેટવર્કીંગ, સિક્યોરિટીના તમારા જ્ઞાનને વિસ્તૃત કરો. - Linux કર્નલની વર્તણૂકને મોનિટર કરવા અને સુધારવા માટે BPF નો ઉપયોગ કરો. - કર્નલને ફરીથી કમ્પાઇલ કર્યા વિના અથવા સિસ્ટમને રીબૂટ કર્યા વિના કર્નલ ઇવેન્ટ્સને સુરક્ષિત રીતે મોનિટર કરવા માટે કોડ ઇન્જેક્ટ કરો. — C, Go અથવા Python માં અનુકૂળ કોડ ઉદાહરણોનો ઉપયોગ કરો. - BPF પ્રોગ્રામ જીવનચક્રની માલિકી દ્વારા નિયંત્રણ લો.

Linux કર્નલ સુરક્ષા, તેની વિશેષતાઓ અને Seccomp

BPF સ્થિરતા, સુરક્ષા અથવા ઝડપને બલિદાન આપ્યા વિના કર્નલને વિસ્તારવાની એક શક્તિશાળી રીત પ્રદાન કરે છે. આ કારણોસર, કર્નલ વિકાસકર્તાઓએ વિચાર્યું કે BPF પ્રોગ્રામ્સ દ્વારા સપોર્ટેડ Seccomp ફિલ્ટર્સ, જેને Seccomp BPF તરીકે પણ ઓળખવામાં આવે છે, તેના અમલીકરણ દ્વારા Seccomp માં પ્રક્રિયા અલગતા સુધારવા માટે તેની વૈવિધ્યતાનો ઉપયોગ કરવો એ સારો વિચાર છે. આ પ્રકરણમાં અમે Seccomp શું છે અને તેનો ઉપયોગ કેવી રીતે થાય છે તે સમજાવીશું. પછી તમે BPF પ્રોગ્રામ્સનો ઉપયોગ કરીને Seccomp ફિલ્ટર્સ કેવી રીતે લખવા તે શીખી શકશો. તે પછી, અમે બિલ્ટ-ઇન BPF હુક્સ જોઈશું જે Linux સુરક્ષા મોડ્યુલ્સ માટે કર્નલમાં સમાવિષ્ટ છે.

Linux સિક્યુરિટી મોડ્યુલ્સ (LSM) એ એક ફ્રેમવર્ક છે જે ફંક્શનનો સમૂહ પૂરો પાડે છે જેનો ઉપયોગ પ્રમાણિત રીતે વિવિધ સુરક્ષા મોડલ્સને અમલમાં કરવા માટે થઈ શકે છે. LSM ને સીધા કર્નલ સ્ત્રોત વૃક્ષમાં વાપરી શકાય છે, જેમ કે Apparmor, SELinux અને Tomoyo.

ચાલો Linux ની ક્ષમતાઓની ચર્ચા કરીને શરૂઆત કરીએ.

લક્ષણો

Linux ની ક્ષમતાઓનો સાર એ છે કે તમારે ચોક્કસ કાર્ય કરવા માટે એક બિનપ્રાપ્તિહીત પ્રક્રિયા પરવાનગી આપવાની જરૂર છે, પરંતુ તે હેતુ માટે suidનો ઉપયોગ કર્યા વિના, અથવા અન્યથા પ્રક્રિયાને વિશેષાધિકૃત બનાવવી, હુમલાની શક્યતા ઘટાડીને અને પ્રક્રિયાને ચોક્કસ કાર્યો કરવા માટે પરવાનગી આપે છે. ઉદાહરણ તરીકે, જો તમારી એપ્લિકેશનને વિશેષાધિકૃત પોર્ટ ખોલવાની જરૂર હોય, તો 80 કહો, પ્રક્રિયાને રૂટ તરીકે ચલાવવાને બદલે, તમે તેને CAP_NET_BIND_SERVICE ક્ષમતા આપી શકો છો.

main.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 અને ખરેખર વપરાશકર્તા ID ને બદલવાની ક્ષમતાનો ઉલ્લેખ કરીશું. રુટ ટુ નોબડી, એટલે કે cap_setuid અને cap_setgid.
• —keep=1 — અમે રુટ એકાઉન્ટમાંથી સ્વિચ કરતી વખતે સ્થાપિત ક્ષમતાઓ રાખવા માંગીએ છીએ.
• —user=“કોઈ નહિ” — પ્રોગ્રામ ચલાવનાર અંતિમ વપરાશકર્તા કોઈ નહીં હોય.
• —addamb=cap_net_bind_service — રુટ મોડમાંથી સ્વિચ કર્યા પછી સંબંધિત ક્ષમતાઓના ક્લિયરિંગને સેટ કરો.
• - -c "./capabilities" - ફક્ત પ્રોગ્રામ ચલાવો.

લિંક્ડ ક્ષમતાઓ એ એક ખાસ પ્રકારની ક્ષમતાઓ છે જે બાળ કાર્યક્રમો દ્વારા વારસામાં મળે છે જ્યારે વર્તમાન પ્રોગ્રામ તેમને execve() નો ઉપયોગ કરીને એક્ઝિક્યુટ કરે છે. માત્ર એવી ક્ષમતાઓ કે જેને સાંકળવાની મંજૂરી છે, અથવા બીજા શબ્દોમાં કહીએ તો, પર્યાવરણીય ક્ષમતાઓ તરીકે, વારસામાં મળી શકે છે.

--caps વિકલ્પમાં ક્ષમતાનો ઉલ્લેખ કર્યા પછી તમે કદાચ આશ્ચર્ય પામી રહ્યા છો કે +eip નો અર્થ શું થાય છે. આ ફ્લેગ્સનો ઉપયોગ ક્ષમતા નક્કી કરવા માટે થાય છે:

-સક્રિય હોવું જ જોઈએ (p);

- ઉપયોગ માટે ઉપલબ્ધ (e);

-બાળ પ્રક્રિયાઓ દ્વારા વારસામાં મળી શકે છે (i).

કારણ કે આપણે cap_net_bind_service નો ઉપયોગ કરવા માંગીએ છીએ, આપણે આ ઈ ફ્લેગ સાથે કરવાની જરૂર છે. પછી આપણે આદેશમાં શેલ શરૂ કરીશું. આ ક્ષમતાઓને બાઈનરી ચલાવશે અને આપણે તેને i ફ્લેગ સાથે ચિહ્નિત કરવાની જરૂર છે. છેલ્લે, અમે ઇચ્છીએ છીએ કે p સાથે સુવિધા સક્ષમ કરવામાં આવે (અમે UID બદલ્યા વિના આ કર્યું). તે cap_net_bind_service+eip જેવું લાગે છે.

તમે ss નો ઉપયોગ કરીને પરિણામ ચકાસી શકો છો. ચાલો પૃષ્ઠ પર ફિટ થવા માટે આઉટપુટને થોડું ટૂંકું કરીએ, પરંતુ તે 0 સિવાય અન્ય સંકળાયેલ પોર્ટ અને વપરાશકર્તા ID બતાવશે, આ કિસ્સામાં 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 નો ઉપયોગ કર્યો છે, પરંતુ તમે libcap નો ઉપયોગ કરીને શેલ લખી શકો છો. વધુ માહિતી માટે, મેન 3 લિબકેપ જુઓ.

પ્રોગ્રામ્સ લખતી વખતે, ઘણી વાર ડેવલપર પ્રોગ્રામને રન સમયે જોઈતી તમામ સુવિધાઓ અગાઉથી જાણતો નથી; વધુમાં, આ સુવિધાઓ નવા સંસ્કરણોમાં બદલાઈ શકે છે.

અમારા પ્રોગ્રામની ક્ષમતાઓને વધુ સારી રીતે સમજવા માટે, અમે 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

આ નીચેની જેમ કંઈક આઉટપુટ કરશે જો 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 છે, તે ફાઈલમાં કર્નલ સોર્સ કોડમાં એક સ્થિર તરીકે વ્યાખ્યાયિત થયેલ છે 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">

રન-સી અથવા ડોકર જેવા કન્ટેનર માટે રનટાઈમ સમયે ક્ષમતાઓ સક્ષમ કરવામાં આવે છે જેથી તેઓને અનપ્રિવિલેજ્ડ મોડમાં ચલાવવાની મંજૂરી મળે, પરંતુ તેમને મોટાભાગની એપ્લિકેશનો ચલાવવા માટે જરૂરી ક્ષમતાઓને જ મંજૂરી આપવામાં આવે છે. જ્યારે એપ્લિકેશનને ચોક્કસ ક્ષમતાઓની જરૂર હોય, ત્યારે ડોકર તેમને --cap-add નો ઉપયોગ કરીને પ્રદાન કરી શકે છે:

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

આ આદેશ કન્ટેનરને CAP_NET_ADMIN ક્ષમતા આપશે, જે તેને ડમી0 ઈન્ટરફેસ ઉમેરવા માટે નેટવર્ક લિંકને ગોઠવવાની મંજૂરી આપશે.

આગળનો વિભાગ બતાવે છે કે ફિલ્ટરિંગ જેવી સુવિધાઓનો ઉપયોગ કેવી રીતે કરવો, પરંતુ એક અલગ તકનીકનો ઉપયોગ કરીને જે અમને પ્રોગ્રામેટિક રીતે અમારા પોતાના ફિલ્ટર્સનો અમલ કરવાની મંજૂરી આપે છે.

સેકકોમ્પ

Seccomp એ સિક્યોર કમ્પ્યુટિંગ માટે વપરાય છે અને તે Linux કર્નલમાં અમલમાં મૂકાયેલ સુરક્ષા સ્તર છે જે વિકાસકર્તાઓને ચોક્કસ સિસ્ટમ કૉલ્સને ફિલ્ટર કરવાની મંજૂરી આપે છે. જોકે સેકકોમ્પ લિનક્સ સાથે ક્ષમતાઓમાં તુલનાત્મક છે, અમુક સિસ્ટમ કોલ્સનું સંચાલન કરવાની તેની ક્ષમતા તેની સરખામણીમાં તેને વધુ લવચીક બનાવે છે.

Seccomp અને Linux લક્ષણો પરસ્પર વિશિષ્ટ નથી અને ઘણી વખત બંને અભિગમોથી લાભ મેળવવા માટે એકસાથે ઉપયોગમાં લેવાય છે. ઉદાહરણ તરીકે, તમે પ્રક્રિયાને CAP_NET_ADMIN ક્ષમતા આપવા માંગો છો પરંતુ તેને સોકેટ કનેક્શન્સ સ્વીકારવાની મંજૂરી આપતા નથી, સ્વીકારો અને સ્વીકારો4 સિસ્ટમ કૉલ્સને અવરોધિત કરો.

Seccomp ફિલ્ટરિંગ પદ્ધતિ SECOMP_MODE_FILTER મોડમાં કાર્યરત BPF ફિલ્ટર્સ પર આધારિત છે, અને સિસ્ટમ કૉલ ફિલ્ટરિંગ પેકેટોની જેમ જ કરવામાં આવે છે.

સેકકોમ્પ ફિલ્ટર્સ PR_SET_SECCOMP ઓપરેશન દ્વારા prctl નો ઉપયોગ કરીને લોડ થાય છે. આ ફિલ્ટર્સ એક BPF પ્રોગ્રામનું સ્વરૂપ લે છે જે seccomp_data માળખું દ્વારા રજૂ કરાયેલ દરેક Seccomp પેકેટ માટે ચલાવવામાં આવે છે. આ માળખું સંદર્ભ આર્કિટેક્ચર, સિસ્ટમ કૉલ સમયે પ્રોસેસર સૂચનાઓ માટે એક નિર્દેશક અને મહત્તમ છ સિસ્ટમ કૉલ દલીલો ધરાવે છે, જે 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 ફિલ્ટર રિટર્ન વેલ્યુનો એક ભાગ errno મૂલ્ય તરીકે વપરાશકર્તા જગ્યાને પસાર કરવામાં આવે છે. ભૂલના કારણને આધારે, વિવિધ ભૂલ મૂલ્યો પરત કરવામાં આવે છે. આગળના વિભાગમાં ભૂલ નંબરોની સૂચિ પ્રદાન કરવામાં આવી છે.

- SECOMP_RET_TRACE - તે પ્રક્રિયાને જોવા અને નિયંત્રિત કરવા માટે જ્યારે સિસ્ટમ કૉલ એક્ઝિક્યુટ કરવામાં આવે ત્યારે અટકાવવા માટે - PTRACE_O_TRACESECCOMP નો ઉપયોગ કરીને ptrace ટ્રેસરને સૂચિત કરવા માટે વપરાય છે. જો ટ્રેસર કનેક્ટેડ ન હોય, તો ભૂલ પરત કરવામાં આવે છે, ભૂલ -ENOSYS પર સેટ કરવામાં આવે છે, અને સિસ્ટમ કૉલ એક્ઝિક્યુટ થતો નથી.

- SECOMP_RET_LOG - સિસ્ટમ કૉલ ઉકેલાઈ ગયો અને લૉગ થયો.

- SECOMP_RET_ALLOW - સિસ્ટમ કૉલની મંજૂરી છે.

ptrace એ ટ્રેસી નામની પ્રક્રિયામાં ટ્રેસીંગ મિકેનિઝમ્સને અમલમાં મૂકવા માટેનો એક સિસ્ટમ કૉલ છે, જેમાં પ્રક્રિયાના અમલને મોનિટર કરવાની અને નિયંત્રિત કરવાની ક્ષમતા છે. ટ્રેસ પ્રોગ્રામ અસરકારક રીતે અમલને પ્રભાવિત કરી શકે છે અને ટ્રેસીના મેમરી રજીસ્ટરમાં ફેરફાર કરી શકે છે. Seccomp સંદર્ભમાં, જ્યારે SECOMP_RET_TRACE સ્ટેટસ કોડ દ્વારા ટ્રિગર કરવામાં આવે ત્યારે ptrace નો ઉપયોગ કરવામાં આવે છે, જેથી ટ્રેસર સિસ્ટમ કૉલને એક્ઝિક્યુટ કરતા અટકાવી શકે છે અને તેના પોતાના તર્કને અમલમાં મૂકી શકે છે.

સેકકોમ્પ ભૂલો

સમય સમય પર, 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 એ એક ઉપયોગિતા છે જે વપરાશકર્તાઓને સેન્ડબોક્સ મિકેનિઝમ વિકસાવવા માટે પરવાનગી આપે છે. હવે ચાલો જોઈએ કે કેવી રીતે સીકોમ્પ સિસ્ટમ કોલ દ્વારા સીધા બોલાવવામાં આવતા ફિલ્ટરનો ઉપયોગ કરીને યુઝર ઇન્ટરેક્શન પ્રોગ્રામ્સ બનાવવામાં આવે છે.

BPF Seccomp ફિલ્ટર ઉદાહરણ

અહીં આપણે બતાવીશું કે અગાઉ ચર્ચા કરેલી બે ક્રિયાઓને કેવી રીતે જોડવી, એટલે કે:

— અમે એક Seccomp BPF પ્રોગ્રામ લખીશું, જે લેવામાં આવેલા નિર્ણયોના આધારે અલગ-અલગ રિટર્ન કોડ્સ સાથે ફિલ્ટર તરીકે ઉપયોગમાં લેવાશે;

prctl નો ઉપયોગ કરીને ફિલ્ટર લોડ કરો.

પ્રથમ તમારે પ્રમાણભૂત લાઇબ્રેરી અને Linux કર્નલમાંથી હેડરોની જરૂર છે:

#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 પર કૂદકો લગાવો, અન્યથા કમાન મેળ ખાતી ન હોવાને કારણે ભૂલ ફેંકવા માટે ઓફસેટ 3 (આ કિસ્સામાં) પર કૂદકો.

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

સોકેટ_ફિલ્ટર સ્ટ્રક્ચરમાં ફિલ્ટર કોડને વ્યાખ્યાયિત કર્યા પછી, તમારે કોડ અને ફિલ્ટરની ગણતરી કરેલ લંબાઈ ધરાવતા સોક_એફપ્રોગને વ્યાખ્યાયિત કરવાની જરૂર છે. પ્રક્રિયાને પછીથી ચલાવવાની ઘોષણા કરવા માટે દલીલ તરીકે આ ડેટા સ્ટ્રક્ચરની જરૂર છે:

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

install_filter ફંક્શનમાં માત્ર એક જ વસ્તુ બાકી છે - પ્રોગ્રામને જ લોડ કરો! આ કરવા માટે, અમે prctl નો ઉપયોગ કરીએ છીએ, PR_SET_SECCOMP ને સુરક્ષિત કમ્પ્યુટિંગ મોડમાં દાખલ કરવાના વિકલ્પ તરીકે લઈએ છીએ. પછી અમે મોડને 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)

હવે તમે સમજો છો કે Seccomp BPF કેવી રીતે કામ કરે છે અને તમે તેની સાથે શું કરી શકો છો તેનો સારો ખ્યાલ છે. પરંતુ શું તમે તેની સંપૂર્ણ શક્તિનો ઉપયોગ કરવા માટે 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 દ્વારા કન્ટેનર રનટાઇમ સુરક્ષા અને વિસંગતતા શોધ પૂરી પાડે છે. તે ડિસ્ટ્રિબ્યુટેડ સિસ્ટમ્સ, સોફ્ટવેર ડિફાઈન્ડ નેટવર્કિંગ, લિનક્સ કર્નલ અને પરફોર્મન્સ એનાલિસિસ વિશે ઉત્સાહી છે.

» પુસ્તક વિશે વધુ માહિતી માટે, કૃપા કરીને મુલાકાત લો પ્રકાશકની વેબસાઇટ
» સમાવિષ્ટોનું કોષ્ટક
» અવતરણ

Khabrozhiteli માટે કૂપન પર 25% ડિસ્કાઉન્ટ - Linux

પુસ્તકના પેપર વર્ઝનની ચૂકવણી કર્યા પછી, ઈ-મેલ પર ઈ-બુક મોકલવામાં આવે છે.

સોર્સ: www.habr.com