Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
gvisor — يعزل الحاويات في بيئة رملية (Sandbox) عبر نواة تطبيق تعمل في فضاء المستخدم تعترض استدعاءات النظام، وتحدّ من وصول نواة المضيف، وتتكامل مع Docker/Kubernetes من خلال بيئة تشغيل OCI. | Kitploit
أدوات/GitHubGitHub/google/gvisor
أمن البنية التحتية السحابيةأدوات دفاعيةأمن الحاوياتالتحليل الديناميكي (عزل)المحاكاة الافتراضية للأمانأمن السحابةالهروب من الحاويةالأفضل في الهروب من الحاوية #11الأفضل في أمن الحاويات #16
19.5k2.0k71منذ 8س 17دتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
الأفضل في التحليل الديناميكي (عزل) #10
الأفضل في المحاكاة الافتراضية للأمان #13
GitHubgoogle/gvisor

gvisor

يعزل الحاويات في بيئة رملية (Sandbox) عبر نواة تطبيق تعمل في فضاء المستخدم تعترض استدعاءات النظام، وتحدّ من وصول نواة المضيف، وتتكامل مع Docker/Kubernetes من خلال بيئة تشغيل OCI.

عرض المستودعالموقع الإلكتروني
مشاركة

gVisor

Build status Issue reviver CodeQL code search

ما هو gVisor؟

يوفر gVisor طبقة قوية من العزل بين التطبيقات قيد التشغيل ونظام التشغيل المضيف. وهو نواة تطبيقية تنفذ واجهة شبيهة بواجهة Linux. وخلافًا لـ Linux، فهو مكتوب بلغة آمنة للذاكرة (Go) ويعمل في مساحة المستخدم.

يتضمن gVisor وقت تشغيل Open Container Initiative (OCI) يُسمى runsc يجعل من السهل العمل مع أدوات الحاويات الموجودة. يتكامل وقت التشغيل runsc مع Docker وKubernetes، مما يسهّل تشغيل حاويات معزولة.

ما الذي ليس gVisor؟

  • gVisor ليس مرشّح استدعاءات نظام (مثل seccomp-bpf)، ولا غلافًا فوق بدائيات العزل في Linux (مثل firejail، AppArmor، إلخ).
  • gVisor أيضًا ليس جهازًا افتراضيًا (VM) بالمعنى اليومي للمصطلح (مثل VirtualBox، QEMU).

يتبنى gVisor نهجًا ثالثًا متميزًا، إذ يوفر العديد من الفوائد الأمنية للأجهزة الافتراضية مع الحفاظ على بصمة موارد أقل، وبدء تشغيل سريع، ومرونة التطبيقات العادية في مساحة المستخدم.

لماذا يوجد gVisor؟

الحاويات ليست صندوقًا رمليًا. فبينما أحدثت الحاويات ثورة في طريقة تطويرنا وتغليفنا ونشرنا للتطبيقات، فإن استخدامها لتشغيل تعليمات برمجية غير موثوقة أو يحتمل أن تكون ضارة دون عزل إضافي ليس فكرة جيدة. وبينما يسمح استخدام نواة واحدة مشتركة بتحقيق مكاسب في الكفاءة والأداء، فإنه يعني أيضًا أن الهروب من الحاوية ممكن بثغرة أمنية واحدة.

gVisor هو نواة تطبيقية للحاويات. فهو يحد من سطح نواة المضيف الذي يمكن للتطبيق الوصول إليه مع منح التطبيق إمكانية الوصول إلى جميع الميزات التي يتوقعها. وخلافًا لمعظم النوى، لا يفترض gVisor أو يتطلب مجموعة ثابتة من الموارد الفيزيائية؛ بل يستفيد من وظائف نواة المضيف الموجودة ويعمل كعملية عادية. وبعبارة أخرى، ينفذ gVisor نظام Linux عن طريق Linux.

لا ينبغي الخلط بين gVisor والتقنيات والأدوات التي تهدف إلى تحصين الحاويات ضد التهديدات الخارجية، أو توفير فحوصات سلامة إضافية، أو الحد من نطاق الوصول لخدمة ما. ينبغي للمرء دائمًا توخي الحذر بشأن البيانات التي تُتاح للحاوية.

التوثيق

يمكن العثور على توثيق المستخدم والبنية التقنية، بما في ذلك أدلة البدء السريع، على gvisor.dev.

التثبيت من المصدر

يُبنى gVisor على x86_64 وARM64. قد تتوفر معماريات أخرى في المستقبل.

لأغراض هذه التعليمات، يتم تغليف bazel وتبعيات البناء الأخرى في حاوية بناء. من الممكن استخدام bazel مباشرة، أو كتابة make help للأهداف القياسية.

المتطلبات

تأكد من تثبيت التبعيات التالية:

  • Linux 5.6+
  • Docker إصدار 17.09.0 أو أحدث

البناء

ابنِ حزمة إصدار مضغوطة (tarball) تحتوي على runsc، وواجهة containerd shim المسماة containerd-shim-runsc-v1، وبعض الملفات التنفيذية الجانبية التي يتوقع runsc العثور عليها في دليل gvisor-bin/ بجواره، ثم استخرجها إلى /usr/local/bin:

make release-tarball DESTINATION=bin/
sudo tar -C /usr/local/bin -xf bin/gvisor.tar.bz2

لبناء مكتبات أو ملفات تنفيذية محددة، يمكنك تحديد الهدف:

make build TARGETS="//pkg/tcpip:tcpip"

البناء مباشرة باستخدام Bazel (بدون Docker)

لا يُوصى باستخدام Bazel مباشرة بسبب الحمل الإضافي، ولكن للبدء:

  • اطّلع على build dockerfile للحصول على القائمة المعيارية للتبعيات المطلوبة.
  • ثبّت واستخدم bazelisk. وإلا، فتأكد من أن إصدار bazel لديك يطابق الإصدار المذكور في ملف .bazelversion.

بعد إعداد التبعيات، يكون استخدام Bazel مشابهًا لـ Makefile:

bazel build -c opt //debian:gvisor-release-tar-bz2

الاختبار

لتشغيل مجموعات الاختبار القياسية، يمكنك استخدام:

make unit-tests
make tests

لتشغيل اختبارات محددة، يمكنك تحديد الهدف:

# Makefile
make test TARGETS="//runsc:version_test"
# Bazel
bazel test //runsc:version_test

Mac OS

تدعم بعض الحزم تشغيل الاختبارات مباشرة على macOS. في وقت كتابة هذا النص، يتطلب gVisor الإصدار 8 من bazel، والذي يمكنك تثبيته عبر homebrew:

brew install bazel@8

# You can then run the tests, e.g.:
$(brew --prefix bazel@8)/bin/bazel test --macos_sdk_version=$(xcrun --show-sdk-version) -- //tools/nogo/... //tools/check{aligned,const,escape,linkname,locks,unsafe}/...

استخدام go get

يستخدم هذا المشروع bazel للبناء وإدارة التبعيات. يتم الاحتفاظ بفرع go اصطناعي متوافق مع أدوات go القياسية للراحة. وهذا مفيد للحزم والمكتبات الخارجية التي تعتمد على حزم gVisor الفرعية (مثل الشبكات في مساحة المستخدم عبر Netstack) لاستيراد تعليمات gVisor البرمجية بلغة Go إلى مشاريع Go الخاصة بها.

اختر هذا الفرع صراحةً باستخدام استعلام الفرع go. يحل @latest إلى master، الذي يتطلب Bazel وغير متوافق مع أدوات Go القياسية:

go get gvisor.dev/gvisor/pkg/tcpip/transport/tcp@go

ملاحظة: عمليات بناء runsc من هذا الفرع غير مدعومة. يتطلب gVisor وrunsc عدة ملفات تنفيذية (بعضها غير مكتوب بلغة Go أصلًا) لكي يعملا. فرع go مدعوم بأفضل جهد ممكن، والتطوير المباشر على هذا الفرع غير مدعوم. يجب أن يحدث التطوير على فرع master، الذي ينعكس بعد ذلك في فرع go.

المجتمع والحوكمة

راجع GOVERNANCE.md للحصول على معلومات حوكمة المشروع.

راجع ADOPTERS.md للحصول على قائمة بالمستخدمين والمتبنين المعروفين في بيئات الإنتاج.

تُعد قائمة بريد gvisor-users وقائمة بريد gvisor-dev نقطتي انطلاق جيدتين للأسئلة والنقاش.

سياسة الأمان

راجع SECURITY.md.

المساهمة

راجع Contributing.md.

تنزيل الأداة