gVisor مقابل seccomp-bpf: عزل الأدوات الهجومية

السماح لوكيل بتشغيل ثغرات يفرض سؤالاً غير مريح: ماذا يحدث حين تكون الأداة المُطلَقة خبيثة، أو يُخطئ الوكيل نفسه؟ كان جوابنا الأول seccomp-bpf، والثاني للأحمال الأعلى خطورةً هو gVisor. وهما لا يتنافسان بل يتراكبان.

seccomp-bpf: رخيص وحاد

يُرشّح seccomp-bpf نداءات النظام على مستوى النواة بتكلفة شبه معدومة. مثالي للأدوات المعروفة: تُعرّف قائمة سماح لما يحتاجه nmap أو ffuf، وكل ما عداها يموت بـ SIGSYS. العيب: الملفات هشّة، ونداء واحد زائد قد يكون طريق هروب.

seccomp:
  default_action: SCMP_ACT_ERRNO
  syscalls:
    - names: [read, write, openat, connect, socket]
      action: SCMP_ACT_ALLOW

gVisor: نواة بينك وبين النواة الحقيقية

يعترض gVisor نداءات النظام في نواة بمساحة المستخدم مكتوبة بـ Go: يظن الملف التنفيذي أنه يكلّم Linux، لكنه يكلّم Sentry. تنخفض مساحة النواة الحقيقية المكشوفة بشدة. تدفع في الأداء، لكنك تكسب عزلاً ضد ثغرات النواة الصِفرية.

كيف نختار

• أداة موثوقة بملف معروف: seccomp-bpf.
• ملف غير موثوق، ثغرة طرف ثالث، برمجية قيد التحليل: gVisor ومعه seccomp-bpf بداخله.
• دائماً: cgroups لحدود المعالج/الذاكرة وسياسات شبكة حسب النطاق.

ما الذي نقدّمه

يختار Gwaihir الصندوق الرملي وفق مستوى الثقة بالأداة لا وفق إعداد عام. الحالة الشائعة تعمل تحت seccomp-bpf للسرعة، والخطرة تقع في gVisor. دفاع متعمّق لا جدار واحد.