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

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

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

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

دليل الأدوات

الفئات

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

الأكثر شعبية

عرض الكل →

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

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

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

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

gvisor

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

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

gVisor

حالة البناء مُحيي المشكلات CodeQL البحث في الشيفرة

ما هو gVisor؟

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

يتضمن gVisor وقت تشغيل مبادرة الحاويات المفتوحة (OCI) يُسمى runsc يجعل من السهل العمل مع أدوات الحاويات الموجودة. يتكامل وقت التشغيل runsc مع Docker وKubernetes، مما يجعل تشغيل الحاويات المعزولة أمرًا بسيطًا.

ما الذي ليس gVisor؟

  • gVisor ليس مرشح استدعاءات نظام (مثل seccomp-bpf)، ولا غلافًا فوق بدائيات العزل في Linux (مثل firejail وAppArmor وغيرها).
  • كما أن gVisor ليس جهازًا افتراضيًا بالمعنى اليومي للمصطلح (مثل 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 أو أحدث

البناء

ابنِ كرة قطران إصدار تحتوي على runsc، وواجهة containerd المسماة 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.

الإصدارات

راجع Releases.

المساهمة

راجع Contributing.md.

تنزيل الأداة