attestos

Linux बूट-प्रमाणन (boot-attestation) छवि और साक्ष्य हार्नेस, यह परखने के लिए कि एक एंटी-चीट विक्रेता वितरण-नाम अनुमतिसूची पर भरोसा करने के बजाय क्या सत्यापित कर सकता है।

तंत्र, खतरा मॉडल, और विक्रेता विनिर्देश plunder707/attested-gaming में हैं। यह रिपॉज़िटरी वह छवि है जो साक्ष्य उत्पन्न करती है।

---

स्थिति: स्रोत मैकेनिक्स पूर्वावलोकन। इंस्टॉल करने योग्य या प्रोडक्शन-विश्वसनीय नहीं।

GitHub Actions रन 31157890393 और 31159951490 ने एक Bazzite-व्युत्पन्न QCOW2 बनाया, उसे QEMU/OVMF के अंतर्गत swtpm के साथ और बिना गेस्ट नेटवर्क के बूट किया, स्थायी EK/AK हैंडल प्रावधानित किए, और गेस्ट के अंदर से SHA-256 PCRs 7, 11, 12, और 15 पर एक रॉ कोट सत्यापित किया। इसकी सीमित रसीद का SHA-256 ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf है। एक अलग वेरिफायर वर्कफ़्लो 31160003873 ने इस रिपॉज़िटरी के अंतिम एजेंट कमिट b918392 को एक पृथक सॉफ़्टवेयर TPM के विरुद्ध चलाया और AK नामांकन, रॉ कोट सत्यापन, रीप्ले अस्वीकृति, हस्ताक्षर-छेड़छाड़ अस्वीकृति, और QEMU/OVMF TPM वायरिंग को पास किया।

बूट किया गया परिणाम Bazzite नीति अवरोधक की भी पुष्टि करता है: कोई UKI फ़ाइल या systemd-stub संकेत मौजूद नहीं था, इच्छित lockdown तर्क अनुपस्थित थे, और PCRs 11 और 15 शून्य रहे। PCR 12 भी शून्य था, लेकिन यह एक स्वतंत्र विफलता नहीं है: एम्बेडेड UKI कमांड लाइन PCR 11 से संबंधित है, जबकि PCR 12 बाहरी कमांड-लाइन इनपुट रिकॉर्ड करता है और जब कोई इनपुट नहीं दिया जाता है तो सही रूप से शून्य रह सकता है। Secure Boot कुंजी नामांकन, UKI-समर्थित कमांड-लाइन मापन, हार्डवेयर उद्गम, इवेंट-लॉग रीप्ले, ट्रांसपोर्ट बाइंडिंग, और बूट-नीति प्रवेश अनसुलझे हैं। कोई भी green रन एक कार्यशील प्रोडक्शन प्रमाणन प्रणाली स्थापित नहीं करता है।

एक अलग Fedora सील-इमेज सकारात्मक नियंत्रण run 31218059725 में दो बार और विलयित-स्रोत शीर्ष पर run 31219745053 में फिर से पास हुआ। यह साबित करता है कि हार्नेस एक अपरिवर्तनीय अपस्ट्रीम-हस्ताक्षरित UKI को बूट कर सकता है, फर्मवेयर-चयनित पथ और लोडेड-फ़ाइल हैश को प्रीबूट निरीक्षण से जोड़ सकता है, गैर-शून्य PCR 11 का अवलोकन कर सकता है, और एक अहस्ताक्षरित .cmdline उत्परिवर्तन को अस्वीकार कर सकता है। यह केवल एक हार्नेस नियंत्रण है: सभी निर्माता, नीति, और प्रोडक्शन विश्वास फ़्लैग असत्य रहते हैं, और यह Bazzite पूर्वावलोकन को इंस्टॉल करने योग्य नहीं बनाता है।

फिर पृथक हस्ताक्षरित PCR 12 नीति-ऐडन लेन run 31234464516 पर दो बार पास हुई। अपस्ट्रीम UKI और PCR 11 बाइट-समान रहे; दोनों हस्ताक्षरित बूटों ने lockdown=confidentiality module.sig_enforce=1 को ठीक एक बार लागू किया और PCR 12 ca62dd5f...a8f5 को पुनरुत्पादित किया; हस्ताक्षर-पश्चात छेड़छाड़ अस्वीकार कर दी गई और शून्य-PCR-12 आधार रेखा पर लौट आई। यह एक सीमित तंत्र साबित करता है, न कि एक तैनाती योग्य कुंजी पदानुक्रम या ऑपरेटिंग-सिस्टम विश्वास नीति।

यह स्रोत समीक्षा और पुनरुत्पादनीय अनुकरण के लिए उपलब्ध है। कोई GHCR छवि प्रकाशित नहीं है और यह एक इंस्टॉल करने योग्य विश्वसनीय वितरण नहीं है।

पूर्ण Bazzite प्रयोग BOOTED_IMAGE_CANARY.md में निर्दिष्ट है। पुनरुत्पादन और स्रोत निर्माण निर्देश BUILDING.md में हैं। UKI आधार साक्ष्य और इसके स्वतंत्र प्रवेश मानदंड UKI_BASE_DECISION.md में दर्ज हैं। हस्ताक्षरित PCR 12 नीति-ऐडन प्रयोग अलग से FEDORA_PCR12_ADDON_CANARY.md में निर्दिष्ट है। माइलस्टोन क्रम और रोक नियम ROADMAP.md में ट्रैक किए जाते हैं। पृथक लोडेड-UKI हार्नेस नियंत्रण FEDORA_SEALED_POSITIVE_CONTROL.md में निर्दिष्ट है।

---

Bazzite में यह क्या जोड़ता है

कुछ भी नहीं हटाया गया है और कुछ भी पैच नहीं किया गया है। चार चीज़ें ऊपर जोड़ी जाती हैं:

1. tpm2-tools और tpm2-tss, जिनकी एजेंट को रनटाइम पर आवश्यकता होती है।
2. एक कर्नेल कमांड लाइन /usr/lib/attestos/cmdline पर, जिसमें lockdown=confidentiality और module.sig_enforce=1 हैं।
3. attestos-provision, एक वन-शॉट यूनिट जो TPM के अंदर अलग स्थायी RSA EK और AK पहचान बनाता है और जब कोई मौजूद हो तो NV स्टोरेज से एंडोर्समेंट प्रमाणपत्र पढ़ता है।
4. attestos-agent, लूपबैक पर सॉकेट-सक्रिय, जो एक सख्त attestos.tpm/v1 पहचान, सक्रियण, या कोट चुनौती का उत्तर कच्चे TPM साक्ष्य के साथ देता है। एजेंट कभी भी विश्वास-निर्णय नहीं लौटाता।

आधार Bazzite ही क्यों है

Bazzite Fedora-व्युत्पन्न है, और Fedora परिवार वही है जिसे एंटी-चीट श्वेतसूचियाँ वर्तमान में अवरुद्ध करती हैं। यहाँ प्रमाणन काम करता है, यह साबित करना सार्थक मामला है। SteamOS पर निर्माण करना कुछ भी प्रदर्शित नहीं करेगा, क्योंकि SteamOS को पहले से ही अनुमति है, इसलिए वहाँ एक सफल डेमो उस पहुँच को अर्जित करेगा जो उसके पास पहले से है।

Bazzite को परतदार होने के लिए भी डिज़ाइन किया गया है। यह एक OCI छवि है, इसलिए यह रिपॉज़िटरी एक Containerfile और एक GitHub Action है, न कि अपने पीछे मिरर और इंस्टॉलर वाला वितरण।

नीति को कर्नेल से पहले प्रमाणित और मापा जाना चाहिए

यह वह हिस्सा है जो तय करता है कि इसका कुछ मतलब है या नहीं। lockdown=confidentiality /dev/mem, चालू कर्नेल के विरुद्ध kprobes, और अहस्ताक्षरित मॉड्यूल लोडिंग को अवरुद्ध करता है। यह गारंटी बेकार है यदि नीति केवल एक बूटलोडर कॉन्फ़िग में रहती है जिसे उपयोगकर्ता संपादित कर सकता है। अन्यथा एक उपयोगकर्ता तर्कों को हटा सकता है, उसी कर्नेल मापन को बूट कर सकता है, और एक ऐसा कोट प्रस्तुत कर सकता है जो लापता नीति के बारे में कुछ नहीं कहता।

एक Unified Kernel Image कर्नेल, initrd, और उसकी एम्बेडेड कमांड लाइन को एक हस्ताक्षरित PE बाइनरी में बाँधता है जिसे PCR 11 में मापा जाता है। एक अलग से हस्ताक्षरित systemd कमांड-लाइन ऐड-ऑन उस अपस्ट्रीम UKI को अपरिवर्तित छोड़ते हुए अतिरिक्त नीति को PCR 12 में विस्तारित कर सकता है। किसी भी मार्ग को सटीक लोडेड आर्टिफैक्ट से जोड़ा जाना चाहिए और वेरिफायर द्वारा रीप्ले किया जाना चाहिए; फ़ाइल की उपस्थिति या गैर-शून्य PCR पर्याप्त नहीं है।

Bazzite UKI नहीं करता, और यह अब संदेह के बजाय पुष्टि है। इसका Containerfile सक्रिय रूप से UKI कर्नेल पैकेजों को बाहर करता है:

dnf5 -y config-manager setopt "*fedora*".exclude="mesa-* kernel-core-* \
    kernel-modules-* kernel-uki-virt-* steam"

systemd-ukify रिपॉज़िटरी में कहीं नहीं दिखता। इसलिए यह छवि जो cmdline फ़ाइल भेजती है वह वर्तमान में केवल इरादे की घोषणा है और कुछ नहीं: UKI के बिना इसे सील करने के लिए कुछ भी नहीं है, उपयोगकर्ता इसे बूटलोडर पर संपादित कर सकता है, और PCR 11 वह नहीं मापता जो डिज़ाइन मानता है कि वह मापता है।

Bazzite को ठीक करना build.sh में एक पंक्ति नहीं है। इसके लिए एक विश्वसनीय प्री-कर्नेल मापन पथ आवश्यक है, चाहे वह छवि के बूट होने के तरीके को बदलकर हो या ऐसे आधार को अपनाकर जो पहले से systemd-stub के माध्यम से बूट होता है।

प्रयोग व्यावहारिक विकल्पों को सीमित करते हैं:

1. Bazzite पर वैसे भी UKI का काम करें और आधार से विचलन स्वीकार करें।
2. एक अपस्ट्रीम सील Fedora UKI का उपयोग करें और PCR 12 में मापे गए एक अलग से हस्ताक्षरित systemd ऐड-ऑन के माध्यम से attestos नीति जोड़ें।
3. एक और प्रमाणित प्री-कर्नेल मापन पथ खोजें। कर्नेल शुरू होने के बाद ही किया गया मापन एक कमज़ोर साक्ष्य वर्ग है और उसे समकक्ष के रूप में प्रस्तुत नहीं किया जाना चाहिए।

कुंजी-प्रवेश समस्या, अनसुलझी

एक अपस्ट्रीम Fedora UKI अपना वितरण हस्ताक्षर बनाए रख सकता है, लेकिन एक अलग attestos नीति ऐड-ऑन को अभी भी फर्मवेयर, Shim, या MOK द्वारा स्वीकृत एक हस्ताक्षर कुंजी की आवश्यकता होती है। एक तृतीय-पक्ष कर्नेल के पास इसी समस्या का बड़ा संस्करण है। तैनाती विकल्प हैं: