Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

फ़ीडसंपर्कगोपनीयता© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
bpfjailer — eBPF LSM आधारित अनिवार्य अभिगम नियंत्रण और jailer | Kitploit
उपकरण/GitHubGitHub/facebookincubator/bpfjailer
प्रमाणीकरण और प्राधिकरणरक्षात्मक उपकरणविशेषाधिकार वृद्धिकंटेनर सुरक्षाकॉन्फ़िगरेशन ऑडिटिंगनेटवर्क एक्सेस कंट्रोल
GitHubfacebookincubator/bpfjailer

bpfjailer

eBPF LSM आधारित अनिवार्य अभिगम नियंत्रण और jailer

रिपॉजिटरी देखें
362191 दिन पहलेKitploit द्वारा समीक्षित

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

BpfJailer

Linux के लिए eBPF आधारित अनिवार्य अभिगम नियंत्रण।

यह प्रोजेक्ट क्लोज़्ड सोर्स BpfJailer का पूर्ण पुनर्लेखन है और पूरी तरह से प्रायोगिक है। यह bpf arena जैसी नई सुविधाओं का उपयोग करता है जो आंतरिक BpfJailer लिखे जाने के समय उपलब्ध नहीं थीं। समस्याओं की अपेक्षा है और ये बग बाउंटी के लिए पात्र नहीं हैं या सुरक्षा निष्कर्ष नहीं मानी जाती हैं। उचित मूल्यांकन के बाद यह आंतरिक क्लोज़्ड सोर्स संस्करण को प्रतिस्थापित करेगा।

BpfJailer प्रक्रियाओं को जेल में डालने के लिए eBPF LSM प्रोग्राम का उपयोग करता है, जिन्हें पॉड कहा जाता है, प्रत्येक TOML नीति से एक भूमिका से बंधा होता है। एक पॉड fork और exec के दौरान विरासत में मिलता है। वैकल्पिक नीति सुविधाएँ:

  • हस्ताक्षरित बाइनरी — निष्पादित बाइनरी को fs-verity और प्रमाणपत्रों के एक नामित सेट से हस्ताक्षर सक्षम करना होगा।
  • kill और ptrace — लक्ष्य भूमिकाएँ/पॉड जिन्हें यह सिग्नल भेज सकता है या अटैच कर सकता है।
  • bpf — किस भूमिका के eBPF मैप और प्रोग्राम एक भूमिका खोल सकती है, या क्या यह बिल्कुल भी bpf(2) कॉल कर सकती है।
  • keyring — किस भूमिका के fs-verity कीरिंग में एक भूमिका प्रमाणपत्र जोड़ सकती है, या क्या यह बिल्कुल भी कीरिंग लिख सकती है।
  • फ़ाइलसिस्टम पथ — फ़ाइलसिस्टम पथों तक पढ़ने और लिखने की पहुँच।
  • निष्पादन योग्य कोड — कौन से पथ निष्पादित किए जा सकते हैं या dll के रूप में उपयोग किए जा सकते हैं।
  • कर्नेल लोडिंग — कर्नेल मॉड्यूल और kexec लोडिंग।
  • IPC — स्वामित्व-जागरूक System V और POSIX संदेश कतारें और साझा मेमोरी, और POSIX ऑब्जेक्ट के लिए चर-विस्तारित नाम पैटर्न।
  • Unix सॉकेट — bind, connect और datagram गंतव्यों के लिए पथनाम और अमूर्त-नाम नीति।
  • माउंट — गंतव्य और फ़ाइलसिस्टम-प्रकार नियम।

अस्वीकृति और जीवनचक्र घटनाएँ पिन किए गए रिंग बफ़र्स में लिखी जाती हैं। bpfjlog मानव-पठनीय BPF निदान और संरचित घटनाएँ प्रिंट करता है और लाइव नीति प्रतिस्थापन के दौरान रिंग बफ़र्स का अनुसरण करता है।

एक बाइनरी user.bpfj.policy.exec xattr के माध्यम से एक भूमिका का दावा कर सकती है और exec समय पर उसमें नामांकित हो जाती है। चल रही प्रक्रियाओं को सीधे भी नामांकित किया जा सकता है, और एक अपरिविलेज्ड प्रक्रिया bpfjsrv/bpfjclient के माध्यम से स्वयं को नामांकित कर सकती है।

घटक

निर्देशिकाबाइनरीउद्देश्य
bpfj/मुख्य लाइब्रेरी और BPF प्रोग्राम: jailer, enforcers, नीति पार्सर, libbpf C++ हेल्पर।
ctl/bpfjctljailer को अटैच, रीलोड, निरीक्षण और डिटैच करने, और प्रक्रियाओं को नामांकित करने के लिए सामान्य प्रयोजन उपकरण।
cmd/bpfjcmdbpfjctl इसके तर्कों के साथ, और वैकल्पिक रूप से इसकी नीति, संकलित। यह argv को अनदेखा करता है, इसलिए इसे स्थिर रूप से लिंक किया जा सकता है और एक इकाई के रूप में fs-verity हस्ताक्षरित किया जा सकता है।
srv/bpfjsrvसॉकेट सक्रिय सर्वर जो अपरिविलेज्ड कॉलर्स को उन भूमिकाओं में नामांकित करता है जो इसकी अनुमति देती हैं।
client/bpfjclientbpfjsrv के लिए न्यूनतम क्लाइंट, बिना किसी libbpf या BPF-टूलचेन निर्भरता के।
log/bpfjlogपिन किए गए निदान और संरचित-घटना रिंग बफ़र्स के लिए उपभोक्ता।
tests/bpfjtestपरीक्षण सूट।

आवश्यकताएँ

  • Linux 6.16 या नया जिसमें BPF LSM सक्षम हो (CONFIG_BPF_LSM=y और lsm= बूट पैरामीटर में bpf)। BpfJailer का परीक्षण केवल 6.16+ पर किया गया है, और पुराने कर्नेल समर्थित नहीं हैं।
  • clang (BPF कोडजेन के लिए), bpftool, और एक C++20 कंपाइलर।
  • libbpf
  • libarena का एक चेकआउट, जो वह arena स्पिन लॉक प्रदान करता है जिसका उपयोग BPF प्रोग्राम करते हैं।
  • हस्ताक्षरित बिल्ड के लिए: openssl, fsverity और setfattr, साथ ही Makefile में सूचीबद्ध स्थिर अभिलेखागार (STATIC=1)।

यदि pkg-config libbpf नहीं ढूँढ पाता है तो LIBBPF_CFLAGS / LIBBPF_LIBS सेट करें। प्रत्येक बिल्ड पर LIBARENA को libarena चेकआउट की ओर इंगित करें:

बिल्डिंग

नीचे दिए गए प्रत्येक make को भी LIBARENA (आवश्यकताएँ देखें) की आवश्यकता होती है, जो कमांड लाइन पर सेट किया गया हो या पर्यावरण में निर्यात किया गया हो।

make                # build/bpfjctl
make STATIC=1       # bpfjctl with no shared object dependencies
make client         # build/bpfjclient, no BPF toolchain needed
make log            # build/bpfjlog
make signing-key    # generate a development signing key and certificate
make signed SIGNING_KEY=... SIGNING_CERT=...   # static, fs-verity signed bpfjctl
make srv  SIGNING_KEY=... SIGNING_CERT=...     # static, signed bpfjsrv
make cmd  SIGNING_KEY=... SIGNING_CERT=... \
     CMD_ARGS="replace-compiled" CMD_POLICY=policy.toml CMD_ROLE=bpfjailer
make clean

सभी आउटपुट build/ के अंतर्गत जाता है। कहीं और बिल्ड करने के लिए BUILD= सेट करें, उदाहरण के लिए make BUILD=build-asan SANITIZE=address,undefined।

परीक्षण

make test

परीक्षणों को root के रूप में चलना होता है, क्योंकि प्रत्येक एक माउंट नेमस्पेस बनाता है और एक bpffs माउंट करता है। make test आह्वान करने वाले उपयोगकर्ता के रूप में बिल्ड करता है और केवल परीक्षण बाइनरी को sudo के अंतर्गत चलाता है।

परीक्षण डिफ़ॉल्ट रूप से क्रमिक रूप से चलते हैं क्योंकि समवर्ती BPF LSM डिटैच प्रभावित कर्नेल को पैनिक कर सकता है। केंद्रित केस के लिए make test TEST_ARGS=Suite.Test का उपयोग करें, और केवल एक डिस्पोज़ेबल VM के अंदर -j N या BPFJTEST_JOBS=N का चयन करें।

उपयोग

sudo bpfjctl check  policy.toml          # parse a policy and report what it holds
sudo bpfjctl attach policy.toml          # load and pin the jailer
sudo bpfjctl replace policy.toml         # reload without releasing jailed tasks
sudo bpfjctl wrap ROLE USER_ID -- CMD    # run CMD in a new pod
sudo bpfjctl enroll ROLE USER_ID PID [NAME=VALUE...] # enroll with variables
sudo bpfjctl show PID                    # pods a process is in
sudo bpfjctl list                        # every pod and its processes
sudo bpfjctl detach                      # unpin and unload

प्रोग्राम डिफ़ॉल्ट रूप से /sys/fs/bpf/bpfj-pins के अंतर्गत पिन किए जाते हैं। इसे बदलने के लिए --bpffs-path और --pin-dir का उपयोग करें। detach चलने तक वे लोडेड रहते हैं।

bpfjctl wrap बिना --drop-cap और गैर-root --uid के कमांड को स्वयं को जेल से हटाने में सक्षम छोड़ देता है। bpfjctl wrap --help देखें।

jailer अटैच रहने के दौरान इसे देखने के लिए sudo build/bpfjlog चलाएँ। BPF निदान stderr पर और संरचित घटनाएँ stdout पर लिखी जाती हैं। जब replace पिन किए गए मैप्स का एक नया सेट स्वैप करता है तो लॉगर स्वचालित रूप से पुनः कनेक्ट हो जाता है।

replace सक्रिय jailer के बगल में एक पूर्ण दूसरा jailer लोड करता है, पॉड सदस्यता, चर और ट्रैक किए गए संसाधन स्वामित्व को माइग्रेट करता है, फिर पिन ट्री को परमाणु रूप से स्वैप करता है। हैंडऑफ के दौरान दोनों ट्री अटैच रहते हैं, forks और नामांकन को माइग्रेशन के साथ समन्वित किया जाता है, और स्वामित्व परिवर्तन जर्नल किए जाते हैं और रीप्ले किए जाते हैं। यदि स्थायी लेआउट संस्करण असंगत हैं या स्थिति को सुरक्षित रूप से कॉपी नहीं किया जा सकता है तो प्रतिस्थापन फेल-क्लोज़्ड होता है।

नीति

base-role = "floor"           # optional: enroll every process on the host
vars = ["vm_uuid"]            # known variable names

[certs]
corp-ca = "MIIDXTCCAkWgAwIBAgIJAK..." # PEM or base64 DER certificate

[roles.floor]
any = true                    # open tracking-only base role

[roles.webserver]
enforce-binary-certs = ["corp-ca"] # execs must be signed by one of these
kill-roles = ["floor"]        # may signal its own pod, plus these roles
ptrace-pod = true             # its own pod only
proc-roles = ["floor"]        # may open proc files for these roles
bpf-pod = true                # only BPF objects from its own pod
lkm-any = false               # deny module and kexec loading
mq-sysv-pod = true            # only SysV queues from its own pod
mq-posix-pod = true           # only POSIX queues from its own pod
shm-sysv-pod = true           # only SysV SHM from its own pod
shm-posix-pod = true          # only POSIX SHM from its own pod
keyring-own = true            # only its own role's keyring

[[roles.webserver.mq-posix-pattern]]
name = "/service-${vm_uuid}-*"
allow = true

[[roles.webserver.shm-posix-pattern]]
name = "/service-${vm_uuid}-*"
allow = true
टूल डाउनलोड करें