المشروع الرئيسي · ParanoidBSD

نظام تشغيل تكون فيه السلطة مملوكة، لا مفترضة

كل اختراق تقريبًا يجري بالطريقة نفسها: برنامج يصل إلى شيء لم يكن مقصودًا له أن يمسّه. ParanoidBSD نظام تشغيل مبنيّ بحيث لا يستطيع ذلك. يُسلَّم كل برنامج ما يحتاجه فقط، وما عداه ليس ممنوعًا فحسب — بل هو خارج متناوله. مبنيّ على HardenedBSD، ومعاد كتابته بلغة C++ حديثة، مع الاحتفاظ بالأصل إلى جانبه ليُفحَص كل تغيير في مقابله.

ادعم حملة Kickstarter المستودع → جرّب نموذج الأمان

اللغةC / C++23

أساسيHardenedBSD 15-STABLE

سطح المكتبKDE Plasma 6

آخر دفعةمؤخرًا

النجوم—

بنية المستودع

pbsd/وحدات C++23 — نواة النظام، ومنقولات فضاء المستخدم، وUDA، وBIFROST، والمُركِّب، والسمة

hbsd/شيفرة HardenedBSD 15-STABLE — الأصل، محفوظًا بوصفه المواصفة

kde/Plasma 6 وKWin وأُطر العمل لموجة سطح المكتب

tools/الجرد، ومراحل إعادة الكتابة الحتمية، والنقل بالوكلاء، ومساعدات Clang

docs/المواصفات، ونموذج الأمان، وحالة النقل، والمنشأ

scripts/سكربت التشغيل على نظام ويندوز الفرعي للينكس (WSL)، ومراقِب، وطرفية تقدّم

بلغة بسيطة

ما هذا، في دقيقة واحدة

المشكلة

نظام التشغيل يقع تحت كل ما تشغّله المؤسسة. ومعظم الأنظمة مبنيّة على عقود من شيفرة أقدم، وتسمح لأي برنامج أن يطلب أي شيء على الإطلاق — ثم يقرّر النظام بعد ذلك أيسمح أم لا. لهذا يمكن لعيب واحد في شيء غير مؤذٍ، كالشيفرة التي ترسم خطًّا على الشاشة، أن ينتهي بسرقة كلمات المرور.

الحل

يغيّر ParanoidBSD ما يستطيع البرنامج طلبه أصلًا. فبدل التحقّق من الإذن بعد الطلب، يسلّم كل برنامج قائمة قصيرة بما يجوز له مسّه، ولا يترك له سبيلًا لتسمية أي شيء آخر. وعيبٌ في جزء واحد يكفّ عن كونه طريقًا إلى البقية.

لمن هو

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

الأمان لا ينبغي أن يبدأ عند طبقة التطبيقات. بل عند نظام التشغيل الذي تحتها. وبقية هذه الصفحة هي الهندسة: ما الذي تغيّر، وكيف جرى فحصه، وما لم يُنجَز بعد.

المشكلة

السلطة المحيطة هي العلّة التي لا تستطيع ترقيعها

في يونكس تقليدي، العملية لا تملك حقّ فتح /etc/master.passwd. هي تطلب فحسب، والنواة تقرّر بعد ذلك، بناءً على مَن تزعم العملية أنها هي. كل عملية تستطيع تسمية كل مورد في النظام. فضاء الأسماء عام ومحيط؛ والفحص فكرة لاحقة متأخّرة.

ولهذا يمكن لعلّة تحليل واحدة في محرّك عرض الخطوط أن تصير سرقة بيانات اعتماد. المحرّك لم يحتج يومًا إلى ملف كلمات السر — لكن لا شيء في المعمارية منعه من أن يطلبه.

يقوم HardenedBSD بعمل جادّ هنا أصلًا: التوزيع العشوائي لتخطيط فضاء العناوين (ASLR)، الذي يُحمِّل البرنامج في موضع مختلف في كل مرّة فلا يستطيع المهاجم تخمين مكان أي شيء؛ وسلامة تدفّق التحكّم (CFI)، التي تمنع توجيه البرنامج إلى شيفرة لم يُبنَ لتشغيلها؛ ومعها تخفيفات مشتقّة من PaX، وSafeStack، ومُخصِّصات ذاكرة مُحصَّنة. يحتفظ PBSD بذلك كله ويغيّر شكل السؤال تحته — من “هل يُسمح لهذه العملية؟” إلى “هل تملك هذه العملية مقبضًا لذلك؟”

طريقتان للإجابة عن نداء نظام واحد

// Ambient authority — the traditional path
int fd = open("/etc/master.passwd", O_RDONLY);
// kernel walks a global namespace, then
// checks uid/gid/MAC after the fact

// Handle nucleus — the PBSD path
auto f = dir_handle.open("master.passwd", Rights::Read);
// there is no global namespace to walk.
// no handle, no name, no operation.

شكل توضيحي للفرق، لا سردٌ حرفيّ للنداءات التي يوجّهها برنامج إلى النواة — أي واجهة برمجة التطبيقات الخاصة بها. والنموذج المُعتمَد في docs/.

نموذجا سلطة متقابلان: في ظل السلطة المحيطة تصل العملية إلى المقابس والتنفيذ وptrace ولا تُمنع من ملف كلمات السر إلا بعد أن تطلبه؛ وفي ظل نواة المقابض لا يمكن تسمية سوى المورد الذي تملك له مقبضًا — **أين يقع الفحص.** على اليسار يمضي الطلب دائمًا ثم يُحكَم عليه بعد ذلك. وعلى اليمين، ثلاث من العمليات الأربع لا تملك اسمًا تسأل به أصلًا، فلا يوجد ما يُرفض.

تفاعلي

تتبّع نداء نظام وهو يعبر النواة

أعطِ العملية بعض المقابض، واختر شيئًا تحاوله، وبدّل بين نموذجَي السلطة. الحكم وتعليله يُحسبان مباشرة داخل متصفحك — هذا نموذج تعليمي للتصميم، لا محاكي نواة.

نواة الصلاحيات — مراقب مرجعي

العملية تحاول…

التتبّع

المقابض التي تملكها العملية

الحكم

في انتظار محاولة

اختر عملية لتمريرها عبر المراقب.

قابل للوصول

مرفوض

“قابل للوصول” يَعُدّ كم عملية من العمليات المذكورة تستطيع هذه العملية تنفيذها أصلًا في ظل النموذج الحالي. في ظل السلطة المحيطة تحدّد الهويةُ إمكانَ الوصول؛ وفي ظل النواة تحدّده المقابض التي تملكها فعلًا.

نموذج تعليمي لتصميم أمان PBSD، كُتب لهذه الصفحة. النواة الحقيقية موجودة في pbsd/؛ والمواصفة في docs/specs/.

النقل

أربع مراحل، ونموذج لا يشهد لنفسه أبدًا

نقل فضاء مستخدم ونواة توزيعة برمجيات بيركلي (BSD) إلى C++23 يدويًّا عملُ عقد كامل. ونقله بمطالبة نموذج لغوي بإعادة كتابة الملفات طريقٌ سريع لإنتاج قمامة معقولة المظهر. وPBSD لا يفعل أيًّا منهما.

المرحلة 1

الجرد

tools/inventory_c_sources.py و clang_cxx23_port.py يُقيّمان كل ملف C حسب الصعوبة ويكتبان c_inventory.csv. لا شيء يُخمَّن بشأن النطاق.

المرحلة 2

مراحل حتمية

run_todo_passes.py يطبّق إعادة كتابة ميكانيكية آمنة في المستويات 0–4. بلا أي نموذج. وكل ما ترفضه مرحلة يُسجَّل في refusals.jsonl بدل أن يُفرَض.

المرحلة 3

حلقة الوكلاء

pbsd.py يملأ الملفات الفارغة والمرفوضة بنموذج DeepSeek Flash مع التصعيد إلى Pro بأقصى جهد استدلالي — 48 عاملًا على Flash و24 على Pro افتراضيًّا. هذا ما تموّله حملة Kickstarter.

المرحلة 4

بوابة التحقّق

تصريف، وASan، وUBSan، وتنفيذ تفاضلي، ومقارنة على مستوى التمثيل الوسيط للمصرّف. والملف الذي يُصرَّف فقط هو غير متحقَّق منه. والإخفاقات تُسجَّل في agent_port_failures.jsonl.

شيطان BSD مرسومًا مرّتين: على اليسار التعويذة الحمراء الأصلية، وعلى اليمين الشكل نفسه كإطار سلكي سماوي، وبينهما علامة يساوٍ — المشروع في صورة واحدة. الشيطان نفسه، والشكل نفسه، معاد بناؤه بتمثيل مختلف — وعلامة اليساوي هي الجزء الذي يجب استحقاقه، ملفًّا بعد ملف، بالتحقّق التفاضلي. شيطان BSD © Marshall Kirk McKusick.

ما الذي يجب أن تعنيه “يساوي”

النقل ادّعاء بالتكافؤ

أن تقول إن ملفًّا نُقل يعني أن تقول إن الجديد يسلك سلوك القديم. هذا ادّعاء، والادّعاءات تحتاج إلى دليل. وإعادة كتابة بلغة C++23 تُترجَم بنجاح ليست إلا إطارًا سلكيًّا يبدو معقولًا؛ ليست الشيطان نفسه بعد.

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

القاعدة التي تجعل هذا قابلًا للدفاع عنه: النموذج لا يشهد لنفسه. هو يقترح، والأدوات الحتمية تقرّر. وكل بند غير قابل للتفاوض في المستودع موجود للحفاظ على هذا الحدّ سليمًا — وهو أيضًا سبب أن النقل لا يمكن تسريعه بمجرّد إنفاق المزيد على الاستدلال وحده.

بنود غير قابلة للتفاوض

قواعد يخضع لها المستودع فعلًا

لا ملف يُعدّ منجزًا قبل أن يجتاز التحقّق التفاضلي أو تحقّق التمثيل الوسيط

الترجمة وحدها تُعامَل على أنها غير متحقَّق منها. على الملف المنقول إمّا أن ينتج سلوكًا ظاهريًّا مطابقًا لسلوك أصل HardenedBSD تحت التنفيذ التفاضلي، أو أن يطابقه على مستوى التمثيل الوسيط. والملفات التي لا تجتاز أيًّا منهما تبقى مفتوحة في سجل النقل ولا تُحتسب في أرقام التقدّم.

انقل بأمانة — ولا “تصلح” علل الأصل بصمت

شجرة HardenedBSD هي المواصفة السلوكية. فإن كان في الأصل عيب، أعاد النقل إنتاجه، لأن الاختبار التفاضلي لا يميّز بين إصلاح وانحدار. والتحسينات تأتي بعد ذلك، وتُسجَّل على حدة، فيكون التغيير ظاهرًا وقابلًا للمراجعة بدل أن يُدفن داخل ترجمة.

الأدوات الحتمية أولًا؛ والنماذج تملأ ما يتبقّى فقط

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

C++ في النواة قائمة بذاتها: -fno-exceptions -fno-rtti

لا يمكن لنواة النظام أن تعتمد على زمن تشغيل C++ مستضاف. بلا استثناءات، وبلا معلومات نوع في زمن التشغيل (RTTI)، وبلا مسارات مكتبة قياسية تحجز من الكومة عند دخول النواة. والقيود مكتوبة في docs/specs/KERNEL_CXX_ABI.md كي يعرف المساهم ما هو مسموح في سياق النواة دون تخمين.

كل وحدة تحتاج إلى مدخل منشأ قبل أن تُعدّ منجزة

docs/PROVENANCE.md يسجّل من أين جاءت كل وحدة وتحت أي ترخيص. وهذا ما يجعل بيان الترخيص أدناه قابلًا للتحقق بدل أن يكون أمنية — يمكنك أن تفحص، وحدةً وحدة، أي شيفرة مشتقّة من HardenedBSD وأيها عمل PBSD جديد.

التراخيص

ترخيصان، مفصولان بصدق

الشيفرة الجديدة في PBSD — النواة، ووحدات C++23، والأدوات — تُقدَّم بشروط Imortek المعتادة: رخصة جنو أفيرو العمومية العامة (AGPL-3.0+)، مجانية للاستخدام الشخصي والجمعيات الخيرية والتعليم والمؤسسات دون 50,000 دولار أسترالي (AUD) سنويًّا، مع ترخيص تجاري متعدّد المستويات فوق ذلك.

الشيفرة المشتقّة من HardenedBSD تبقى تحت ترخيص BSD الأصلي. لا يمكن إعادة ترخيصها، وImortek لا يدّعي ذلك. docs/PROVENANCE.md هو السجلّ الذي يبيّن أي شيفرة تتبع أي ترخيص.

شروط الترخيص كاملة →

AGPL-3.0+ & تجاري

عمل PBSD الجديد

pbsd/, tools/, scripts/، ونواة الصلاحيات، وUDA، وBIFROST، والمُركِّب، والسمة.

BSD (بلا تغيير)

مشتقّ من HardenedBSD

hbsd/ وكل ملف منقول يعود إليه. الشروط الأصلية، والإسناد الأصلي.

لمن هو

نظام تشغيل يصعب اقتحامه

أغلب الاقتحامات تستغل النوع نفسه من الخطأ: برنامج يصل إلى ذاكرة لم يكن يُفترض أن يمسّها. يعيد ParanoidBSD بناء نظام موثوق بلغة تجعل هذا الخطأ أصعب بكثير، ويعطي كل برنامج ما يحتاجه فعلًا من صلاحية وصول لا أكثر.

موردو الدفاع والحكومة

بدأ المشترون يشترطون برمجيات مبنية بلغات تُغلق فئات كاملة من الهجمات. والبدء من الصفر يكلّف عقدًا. هذا ينقل نظامًا مُجرَّبًا بدلًا من ذلك، ويحتفظ بسجل مكتوب لكل ملف غيّره وكيف فُحص ذلك التغيير.

معدّات تبقى في الميدان سنوات

متحكّمات المصانع، والأجهزة الطبية، وعتاد المرافق. حين يظهر عيب لا تستطيع غالبًا أن تدفع تحديثًا وحسب. هذا يحدّ من المدى الذي يبلغه المتسلّل بعد دخوله، لأن أي برنامج لا يستطيع تجاوز ما سُلِّم إليه.

الجامعات وباحثو الأمن

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

هل ترى حالتك هنا؟ هذا مفتوح للاختبار التجريبي الآن، ومن بُني لأجلهم هم من تغيّره ملاحظاتهم فعلًا. كن مختبِرًا تجريبيًّا →

حملة Kickstarter مباشرة · تُغلَق في 12 نوفمبر 2026

النقل يعمل على قدرة حوسبة لا يملكها

المراحل الحتمية مجانية. أما حلقة الوكلاء التي تملأ البقيّة — وتشغيلات التحقّق التي تقف بوابةً أمامها — فليست كذلك. هذا هو كل المطلوب.

ادعمها على Kickstarter انظر أين يذهب المال اقرأ الشيفرة أولًا