Toolbox: विकास के तहत कोड में बग और मैलवेयर से बचाव के लिए पृथक विकास वातावरण

आप अपने घर के बिना एक सतत उपयोगकर्ता कंटेनर चाहते हैं? बस आवश्यकता/उपयोगकेस को बेहतर ढंग से समझने की कोशिश कर रहा हूं। - मान लीजिए कि इसकी तुलना सिर्फ एक मानक फेक अवे फेडोरा कंटेनर चलाने से की जाती है?

एक यूनिक्स खाते पर विचार करें जिसका उपयोग घर और काम दोनों के लिए किया जाता है। एक कार्य कंटेनर के लिए, मैं कंटेनर में केवल अपनी कार्य निर्देशिका को माउंट करना पसंद कर सकता हूं।

एक अविश्वसनीय जीयूआई ऐप पर विचार करें। फ़ाइलों को लोड/सहेजने के लिए इसे केवल एक विशिष्ट फ़ोल्डर तक पहुंच की आवश्यकता हो सकती है। इसे मेरे .ssh फ़ोल्डर और अन्य असंबंधित फ़ाइलों तक पहुंच की आवश्यकता नहीं है।

सुरक्षा में सुधार के लिए, Chrome OS डिफ़ॉल्ट रूप से होस्ट से फ़ोल्डर को कंटेनर में साझा नहीं करता है। वहां, यदि आप अपने होम डायरेक्टरी या यूएसबी ड्राइव से कंटेनरों को डेटा प्रदान करना चाहते हैं, तो आप इसे स्पष्ट रूप से साझा करते हैं।

यदि आप अपने सभी डेटा को डिफ़ॉल्ट रूप से अविश्वसनीय कंटेनर देते हैं, तो सुरक्षा सुविधा के रूप में कंटेनरीकरण महत्वपूर्ण मूल्य खो देता है!

@juhp मैं देख रहा हूं कि आप हास्केल पैकेज के साथ एक अच्छा सौदा करते हैं। मान लें कि आपके द्वारा दूरस्थ रूप से स्थापित किए गए हास्केल पैकेजों में से एक से समझौता किया गया है। क्या हास्केल पैकेज को आपके .ssh फ़ोल्डर या आपके बिटकॉइन वॉलेट तक पहुंच की आवश्यकता है? डिफ़ॉल्ट रूप से अपने हास्केल देव वातावरण में सब कुछ क्यों साझा करें?

हाल ही में एक एनपीएम मॉड्यूल था जो अभी भी स्थानीय बिटकॉइन को स्थापित कर सकता था:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-seal-from-bitcoin-wallets

मॉड्यूल लोकप्रिय था और वास्तव में मेरी टीम ने इसे हमारे पेड़ में स्थापित किया था। हम बिटकॉइन चोरी को ट्रिगर करने के लिए अन्य मानदंडों को पूरा नहीं करते हैं, लेकिन यह जोखिम पूरी तरह से कम हो गया होता अगर हमारे देव पर्यावरण में डिफ़ॉल्ट रूप से हमारी होम निर्देशिकाओं तक पूर्ण पहुंच नहीं होती। किसी भी कर्मचारी ने अपने बिटकॉइन वॉलेट को इस विकास के माहौल में साझा करने का विकल्प नहीं चुना होगा।

यह पूरी तरह से मान्य है लेकिन कठिन होने वाला है।

व्यावहारिक रूप से, मुझे लगता है कि सबसे अच्छा तरीका टूलबॉक्स को अलग-अलग उपयोगकर्ताओं के रूप में चलाना आसान बनाना है (क्षणिक रूप से नए यूआईडी बनाएं, प्रत्येक अपने स्वयं के /home ) - ऐसा करने के लिए एक विशेषाधिकार प्राप्त सिस्टम सेवा की आवश्यकता होती है।

अब यदि आप कुछ फ़ाइलें साझा करना चाहते हैं जैसे केवल पढ़ने के लिए - यह गड़बड़ हो जाती है।

क्या निर्देशिका बाइंड-माउंट से फ़ाइलों/डीआईआर को बाहर करना संभव है?

यह सुनिश्चित करने के लिए कि मैं चुनौती को समझता हूं, मैं देखता हूं कि होम निर्देशिका को बढ़ाना कोड की एक पंक्ति में होता

    --volume "$HOME":"$HOME":rslave

लेकिन यहां चुनौती अभी भी जीयूआई ऐप्स और कुछ अन्य सुविधाएं काम कर रही है, क्योंकि उन सुविधाओं की अपेक्षा है कि कंटेनर के अंदर और बाहर का उपयोगकर्ता समान है?

यह वास्तव में एक महत्वपूर्ण विशेषता है। मुझे लगता है कि डिफ़ॉल्ट रूप से घर को माउंट करना ठीक है, लेकिन एक कंटेनर का उपयोग अविश्वसनीय तरीके से करना संभव होना चाहिए। एक कंटेनर में घर बढ़ाना यह मानता है कि आप कंटेनर पर भरोसा करते हैं, जो कि एक फेंकने वाले कंटेनर में अक्सर ऐसा नहीं होता है। यहां तक ​​​​कि कुछ एनपीएम मॉड्यूल का परीक्षण करने जैसे साधारण मामलों में भी, मैं मन की शांति चाहता हूं कि यह मेरे होम फ़ोल्डर को बर्बाद नहीं करेगा।

@markstos शायद आप परीक्षण कर सकते हैं कि आप होम माउंट के बिना क्या कर सकते हैं या यदि केवल एक विशिष्ट डीआईआर (सीडब्ल्यूडी) बढ़ते हैं?

@juhp वास्तव में यह मेरे लिए शोस्टॉपर था - इस लापता फीचर में भाग लेने के बाद मैंने सिल्वरब्लू का मूल्यांकन करना बंद कर दिया। अगर इसे संबोधित किया जाता है, तो मैं सिल्वरब्लू को दूसरा रूप दे सकता हूं। मुझे यह जानकर भी निराशा हुई कि उबंटू कंटेनर को कैसे चलाना है, यह पता लगाना आसान नहीं था, जो कि मैं पहले इस्तेमाल किया गया ओएस है।

यदि फेडोरा अन्य लिनक्स डिस्ट्रो से आने वाले उपयोगकर्ताओं का स्वागत करना चाहता है, तो अपने पुराने डिस्ट्रो को एक कंटेनर में चलाना आसान बनाना शुरू करने के लिए एक अच्छी जगह होगी।

@markstos धन्यवाद - मैं सिर्फ एक और टूलबॉक्स उपयोगकर्ता हूं। :-)
मैं इस बात से पूरी तरह सहमत हूं कि अधिक ओएस का समर्थन करने के लिए टूलबॉक्स का विस्तार करना वास्तव में बहुत उपयोगी होगा।
ध्यान दें कि टूलबॉक्स सिल्वरब्लू (अर्थात अन्य फेडोरा संस्करणों पर) के बिना भी काम करता है।

@juhp वास्तव में यह मेरे लिए शोस्टॉपर था - एक बार जब मैं इस लापता विशेषता में भाग गया तो मैंने सिल्वरब्लू का मूल्यांकन करना बंद कर दिया

आपने पहले क्या किया? क्या कोई अन्य उपकरण/दृष्टिकोण है जिसका आप उपयोग कर रहे थे जो सिल्वरब्लू पर काम नहीं करता था?

आपको कुछ भी नहीं रोकता है उदाहरण के लिए एक डिस्पोजेबल वीएम (क्यूब्सओएस जैसे) का उपयोग करना, या उस मामले के लिए एक कस्टम स्क्रिप्ट होना जो इस धागे से कुछ सुझावों को लागू करता है। यकीनन, हमें सिल्वरब्लू में क्यूबोस जैसी कार्यक्षमता में अधिक राय और निर्माण करना चाहिए।

लेकिन वैसे भी मौजूदा वीएम और कंटेनर तकनीक है। वास्तव में toolbox आज वास्तव में स्क्रिप्ट का एक समूह है जो मेजबान के साथ जानबूझकर podman धुंधला कर देता है। यदि आप एकीकरण नहीं चाहते हैं, तो आप podman run से शुरू कर सकते हैं ... क्योंकि यह डिफ़ॉल्ट है।

@cgwalters मैं अपने निजी लैपटॉप पर क्रोम ओएस का उपयोग शुरू कर देते हैं और के माध्यम से वी एम में एक कंटेनर के भीतर चल रहा है मेरी विकास पर्यावरण (और बाकी लगभग सब कुछ) होने के सुरक्षा की सराहना करने के लिए आ Crostini परियोजना। मुझे यह पसंद है कि यह GUI ऐप्स के साथ-साथ कमांड लाइन ऐप्स को भी सपोर्ट करता है। मुझे यह भी पसंद है कि कंटेनर डिफ़ॉल्ट रूप से निजी होते हैं। मुझे उनके साथ डेटा फ़ोल्डर या यूएसबी ड्राइव स्पष्ट रूप से साझा करना है। दूसरी ओर, उन कंटेनरों में साउंड और वेलैंड सपोर्ट अपने आप सेट हो जाता है।
यूआरएल
मैं इसके बजाय अपने कार्य लैपटॉप पर उपयोग करने के लिए समान समाधानों का मूल्यांकन कर रहा हूं। एक विकल्प होगा नेवरवेयर का क्लाउडरेडी-- पीसी हार्डवेयर के लिए एक ओपन सोर्स क्रोम ओएस। कभी-कभी ऐसे बंदरगाह होते हैं जो क्रॉस्टिनी दुर्घटनाग्रस्त हो जाते हैं, डेटा खो जाता है और फिर से शुरू करना आवश्यक होता है। इसी कारण से, मैं अभी ChromeOS / Crostini पर दोहरीकरण करने से हिचकिचाता हूं।

सिल्वरब्लू भी तब तक आकर्षक लग रहा था जब तक मैंने पाया कि यह बॉक्स से बाहर उबंटू कंटेनरों का समर्थन नहीं करता है और यह मेरे व्यक्तिगत डेटा को उन कंटेनरों के साथ साझा करता है जिन पर मैं भरोसा नहीं करना चाहता। मैंने क्लियर लिनक्स को भी देखा। कंटेनरों में लगभग सब कुछ चलाने की इसकी समान अवधारणा है। मैं इंटेल और x86 के साथ घनिष्ठ संबंधों से रोमांचित नहीं हूं। यह भी मुख्य रूप से एक डेस्कटॉप ओएस नहीं है। एक अंतिम (डिफ़ॉल्ट?) विकल्प उबंटू के साथ डेस्कटॉप के रूप में रहना और मेरे विकास कार्य को एलएक्सडी कंटेनरों में स्थानांतरित करना होगा, जो क्रोम की क्रॉस्टिनी उपयोग कर रहा है। मुझे अपने काम और निजी लैपटॉप के बीच एलएक्सडी कंटेनरों की प्रतिलिपि बनाने में सक्षम होना चाहिए, भले ही होस्ट ओएस अलग हो। एलएक्सडी टेम्पलेट्स का उपयोग करते हुए, मुझे वेलैंड समर्थन के लिए कंटेनरों में पर्याप्त मात्रा में एक टेम्पलेट साझा करने में सक्षम होना चाहिए।

साइड नोट: रिदमबॉक्स को बनाए रखने के सभी वर्षों के लिए धन्यवाद!

शायद मैं toolbox के मिशन को गलत समझता हूं। रीडमी से:

.. इन प्रणालियों का इरादा होस्ट पर सॉफ़्टवेयर की स्थापना को हतोत्साहित करना है

क्यों? डिफ़ॉल्ट रूप से अपने सभी व्यक्तिगत डेटा को डिफ़ॉल्ट रूप से कंटेनर में साझा करना है, मुझे नहीं लगता कि बेहतर सुरक्षा का दावा किया जा सकता है।

शेष संभावित लाभ अलगाव होगा, इसलिए आप सॉफ़्टवेयर के परस्पर विरोधी संस्करणों को साथ-साथ स्थापित कर सकते हैं।

यदि हमेशा साझा करने वाला व्यवहार बना रहता है, तो डॉक्स को अपडेट करना मददगार हो सकता है स्पष्ट करें कि toolbox आपकी संपूर्ण होम निर्देशिका को कंटेनरों में साझा करता है, कि व्यवहार को अक्षम नहीं किया जा सकता है और इसका उपयोग अविश्वसनीय के साथ नहीं किया जाना चाहिए कंटेनर।

मुझे लगता है कि मैं सीधे पॉडमैन का उपयोग कर सकता हूं, लेकिन मुझे जीयूआई एकीकरण के साथ एक कंटेनर समाधान में दिलचस्पी थी। podman साथ इसे कैसे पूरा किया जाए, इस पर खोज करते समय, toolbox का उपयोग करना अनुशंसित तरीका है:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos यदि आप रुचि रखते हैं, तो मैंने PR #298 बनाया है जो एक Ubuntu 19.04 छवि बनाता है।

मुझे लगता है कि यहाँ कुछ भ्रम है।

हमारा README.md पिछले कुछ महीनों में थोड़ा बड़ा और रूपांतरित हुआ है, और शायद इसे समझना थोड़ा कठिन है। पहले इसे केवल OSTree-आधारित Fedoras पर Hacking कहा जाता था।

यदि आप सिल्वरब्लू (या उस मामले के लिए कोई अन्य ओएसटी-आधारित ओएस) स्थापित करते हैं तो ओएस को डीबग करने या विकास वातावरण स्थापित करने की कठिनाई तुरंत स्पष्ट हो जाती है। उस समस्या को हल करने के लिए टूलबॉक्स मौजूद है।

.. इन प्रणालियों का इरादा होस्ट पर सॉफ़्टवेयर की स्थापना को हतोत्साहित करना है

क्यों? डिफ़ॉल्ट रूप से अपने सभी व्यक्तिगत डेटा को डिफ़ॉल्ट रूप से कंटेनर में साझा करना है, I
नहीं लगता कि बेहतर सुरक्षा का दावा किया जा सकता है।

सुरक्षा एक अतिभारित शब्द है। टूलबॉक्स इसके बारे में कोई दावा नहीं करता है।

कई दशकों से, आपके यूआईडी के रूप में चलने वाली कोई भी प्रक्रिया आपकी निजी क्रिप्टोग्राफ़िक कुंजियों, दस्तावेज़ों, फ़ोटो आदि को देख सकती है और यहां तक ​​कि आपको बिना जाने पूरे ग्रह पर आधे रास्ते तक पहुंचा सकती है। यह मुफ़्त सॉफ़्टवेयर क्लाइंट OSes की यथास्थिति है।

फ्लैटपैक प्रत्येक ग्राफिकल एप्लिकेशन और ऑपरेटिंग सिस्टम को अपने स्वयं के सुरक्षा डोमेन में अलग करके बदलता है। सिल्वरब्लू सीधे होस्ट ओएस छवि के अंदर सॉफ़्टवेयर स्थापित करना मुश्किल बनाकर इस अलगाव को मजबूत करता है। तो, एक सहज उपयोगकर्ता अनुभव के लिए, आपको वास्तव में फ़्लैटपैक्स के रूप में शिप किए गए एप्लिकेशन का उपयोग करने की आवश्यकता है।

हालाँकि, जैसा कि मैंने शीर्ष पर उल्लेख किया है, यह लॉक डाउन OS छवि समस्याओं का अपना सेट प्रस्तुत करती है। हम उन्हें कैसे हल करते हैं यह सुविधा और सुरक्षा के बीच एक समझौता है। समाधान जितना अधिक क्रांतिकारी होगा, मौजूदा लिनक्स उपयोगकर्ताओं के लिए सिल्वरब्लू को अपनाना उतना ही कठिन होगा।

फिलहाल, टूलबॉक्स सुरक्षा को अपनाने की ओर झुकता है; क्योंकि इस बात पर ध्यान दिए बिना कि आप टूलबॉक्स का उपयोग कर रहे हैं या नहीं, सिल्वरब्लू मुफ्त सॉफ्टवेयर क्लाइंट ओएस की स्थिति में काफी सुधार करता है और इसे उपयोगकर्ता के हाथों में प्राप्त करना एक सकारात्मक कदम होगा।

साथ ही, यह केवल सुरक्षा के बारे में नहीं है। यह स्थिरता के बारे में भी है।

पारंपरिक लिनक्स वितरण का परीक्षण करना बहुत मुश्किल है। दुनिया भर में यादृच्छिक दर्पणों पर यादृच्छिक योगदानकर्ताओं द्वारा पैकेज और दर्पण हमेशा अपडेट किए जा रहे हैं - संयोजन विस्फोट को केवल फ्रीज की विस्तृत प्रणाली द्वारा प्रबंधित किया जा सकता है। जब चीजें गलत हो जाती हैं, और वे करते हैं, तो उपयोगकर्ता के लिए अपडेट को वापस करना भी बहुत मुश्किल होता है, और अपडेट के बीच में बिजली कटौती जैसी चीजें सिस्टम को पूरी तरह से तोड़ सकती हैं।

एक OSTree-आधारित OS वह सब बदल देता है।

मुझे लगता है कि मैं सीधे पॉडमैन का उपयोग कर सकता हूं, लेकिन मुझे जीयूआई के साथ एक कंटेनर समाधान में दिलचस्पी थी
एकीकरण। पॉडमैन के साथ इसे कैसे पूरा किया जाए, इस पर खोज करते समय, टूलबॉक्स का उपयोग करना है
अनुशंसित दृष्टिकोण:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

सवाल यह है कि आप ग्राफिकल एप्लिकेशन चलाने के लिए पॉडमैन का उपयोग क्यों करना चाहते हैं? :)

सामान्य तौर पर, GUI ऐप्स चलाने के लिए पॉडमैन (या एक OCI कंटेनर) एक खराब विकल्प है। यही कारण है कि फ्लैटपैक मौजूद है और टूलबॉक्स उससे प्रतिस्पर्धा नहीं करता है।

हालांकि, एक ओवरलैप है, इस अर्थ में कि टूलबॉक्स कंटेनरों में कुछ डेस्कटॉप एकीकरण है, और कुछ ऐसे मामले हैं जहां एक गैर-फ्लैटपैक जीयूआई ऐप चलाने की क्षमता तत्काल अल्पावधि में बेहद उपयोगी है। यह हो सकता है कि आप जिस एप्लिकेशन को चाहते हैं वह अभी तक फ़्लैटपैक नहीं किया गया है, या हो सकता है कि फ़्लैटपैक संस्करण में कुछ सुविधाएं गुम हों। ऐसा हो सकता है कि आप किसी ऐसी लाइब्रेरी पर काम कर रहे हों जिसका उपयोग ग्राफिकल एप्लिकेशन द्वारा किया जाता है, और आप यह देखने के लिए कि आपकी लाइब्रेरी अपेक्षित रूप से काम कर रही है या नहीं, आप जल्दी से एकबारगी परीक्षण प्रोग्राम चलाना चाहते हैं।

टूलबॉक्स, वास्तव में, ऐसे मामलों में मदद कर सकता है, लेकिन यह कहने से अलग है कि टूलबॉक्स का प्राथमिक उद्देश्य ग्राफिकल अनुप्रयोगों को कंटेनरीकृत करना है। टूलबॉक्स का प्राथमिक उद्देश्य आपको OSTree-आधारित OS पर अपनी हैकिंग करने देना है।

अब, यदि आप गनोम बिल्डर जैसे कंटेनर-देशी आईडीई का उपयोग कर रहे थे, जिसे फ़्लैटपैक के रूप में भेजा जाता है, और जिस सॉफ़्टवेयर पर आप काम कर रहे हैं, उसे बनाने और चलाने के लिए स्वचालित रूप से एक कंटेनर सेट करते हैं, तो आपको टूलबॉक्स की बिल्कुल भी आवश्यकता नहीं होगी।

हालांकि, हर कोई गनोम बिल्डर का उपयोग नहीं करता है, और विजुअल स्टूडियो कोड जैसे सबसे लोकप्रिय आईडीई कंटेनर-देशी नहीं हैं। इसलिए, टूलबॉक्स।

@debarshiray विचारशील और गहन प्रतिक्रिया के लिए धन्यवाद। मैंने ऊपर जो उदाहरण दिया वह ग्राफिकल ऐप्स के लिए नहीं था, जिसे फ़्लैटपैक द्वारा कवर किया जा सकता है। मैंने Node.js विकास करने का उदाहरण दिया। Node.js निर्भरता श्रृंखला में हाल ही में वास्तविक मैलवेयर था जो स्थानीय क्रिप्टो वॉलेट से चोरी कर सकता था। SSH कुंजियों को उतनी ही आसानी से चुराया जा सकता है। जबकि रीडमे का कहना है कि परियोजना डेवलपर्स को लक्षित करती है, शेयर-के-कंटेनर-बाय-डिफॉल्ट कुछ भी डेवलपर्स को उस तरह के हमले से सुरक्षित नहीं करता है।

टूलबॉक्स किसी भी अविश्वसनीय निर्भरता के साथ सीएलआई विकास करते समय व्यक्तिगत फाइलों की चोरी से सुरक्षा प्रदान नहीं करता है। आधुनिक ओपन सोर्स सॉफ़्टवेयर की जटिलता को देखते हुए, डिपेंडेंसी ट्री के कुछ हिस्से ऐसे होंगे जिन पर भरोसा नहीं किया जाना चाहिए।

मुझे लगता है कि वर्तमान रीडमी भ्रामक है: "कंटेनर में पूरी तरह से अनपेक्षित" चलाना सुरक्षा की तरह लगता है, लेकिन यह केवल सुरक्षा थिएटर है-- सभी व्यक्तिगत फाइलें कंटेनर में पहुंच योग्य हैं। ऊपर आप स्पष्ट करते हैं कि टूलबॉक्स सुरक्षा के बारे में कोई दावा नहीं करना चाहता है। मुझे लगता है कि यह स्पष्ट करने के लिए रीडमे में शामिल करने के लिए एक उपयोगी बयान होगा कि कंटेनरों के उपयोग के बावजूद, यह सुविधा के लिए एक उपकरण है सुरक्षा नहीं।

@debarshiray विचारशील और गहन प्रतिक्रिया के लिए धन्यवाद। मैंने जो उदाहरण दिया
ऊपर एक ग्राफिकल ऐप के लिए नहीं था जिसे फ़्लैटपैक द्वारा कवर किया जा सकता है। मैंने दिया
Node.js विकास करने का उदाहरण। Node.js में हाल ही में वास्तविक मैलवेयर था
निर्भरता श्रृंखला जो स्थानीय क्रिप्टो वॉलेट से चोरी कर सकती है। SSH कुंजियाँ चोरी हो सकती हैं
उतनी ही आसानी से। जबकि README का कहना है कि परियोजना डेवलपर्स को लक्षित करती है,
शेयर-साथ-कंटेनर-बाय-डिफॉल्ट डेवलपर्स को उस तरह के हमले से सुरक्षित नहीं करता है।

हां, इस समय टूलबॉक्स केवल छवि-आधारित ओएस के भीतर पारंपरिक पैकेज-आधारित वातावरण को पुन: पेश करने का प्रयास करता है।

मुझे वर्तमान रीडमे भ्रामक लगता है: "कंटेनर में पूरी तरह से अप्रभावित" चल रहा है
सुरक्षा की तरह लगता है, लेकिन यह केवल सुरक्षा थियेटर है-- सभी व्यक्तिगत फाइलें यहां पहुंच योग्य हैं
बर्तन। ऊपर आप स्पष्ट करते हैं कि टूलबॉक्स सुरक्षा के बारे में कोई दावा नहीं करना चाहता है।
मुझे लगता है कि यह स्पष्ट करने के लिए README में शामिल करने के लिए एक उपयोगी कथन होगा कि इसके बावजूद
कंटेनरों का उपयोग, यह सुविधा के लिए एक उपकरण है सुरक्षा नहीं।

कमिट c047659c1d85ca982374da5c58ee7a24ba3847bd वह जगह है जहाँ उस लाइन को जोड़ा गया था। मेरा मानना ​​​​है कि @cgwalters का कहना है कि आपके पास टूलबॉक्स कंटेनर के अंदर केवल अपने स्वयं के यूआईडी तक पहुंच है और वास्तविक रूट (यानी होस्ट पर यूआईडी 0) न तो शामिल है और न ही आपके लिए उपलब्ध है।

मेरी भी यही समस्या है। मैंने सिल्वरब्लू को इस उम्मीद के साथ स्थापित किया कि मैं ऐसे सॉफ़्टवेयर को चलाने में सक्षम हो जाऊं, जिस पर मुझे पूरी तरह से भरोसा न हो, इस बात की चिंता किए बिना कि यह मेरी SSH कुंजियों और अन्य संवेदनशील जानकारी को चुरा लेता है।

यह अहसास कि टूलबॉक्स मुझे ऐसा करने की अनुमति नहीं देता है, एक बड़ी निराशा थी और इसने मुझे शुरुआत में सिल्वरब्लू के उपयोग पर पुनर्विचार करने के लिए प्रेरित किया। व्यक्तिगत रूप से, मुझे मुख्य OS स्थापना की परवाह नहीं है। मैं इसे हमेशा पुनः स्थापित कर सकता हूं। मैं जिस जानकारी को वास्तव में अलग रखना चाहता हूं वह मेरे होम डायरेक्टरी में स्थित है।

क्या यह निर्दिष्ट करना संभव होगा कि होम डायरेक्टरी के किन हिस्सों को ठीक से साझा किया गया है? यदि कोई केवल उन निर्देशिकाओं को श्वेतसूची में डाल सकता है जो टूलबॉक्स (शायद डेस्कटॉप कॉन्फ़िगरेशन से संबंधित हैं, आदि) के लिए आवश्यक हैं, तो यह बहुत सारे मुद्दों को हल करेगा।

अब, मैं सुरक्षा के मुद्दों से पूरी तरह अवगत हूं। चूंकि मैं कई वर्षों से क्यूब्स ओएस का उपयोग कर रहा हूं, अलगाव की समस्या एक कठिन है। यहां तक ​​​​कि अगर आप होम डायरेक्टरी की रक्षा करते हैं, तो यह पर्याप्त नहीं होगा क्योंकि कंटेनर के अंदर चलने वाला प्रोग्राम हमेशा क्लिपबोर्ड जैसे कंटेनरों के बीच संचार के अन्य साधनों का लाभ उठा सकता है। मुझे इसके बारे में पता है, और मैं पूर्ण क्यूब्स स्थापना की तुलना में टूलबॉक्स जैसी किसी चीज़ की सुविधा के बदले में उनमें से कुछ जोखिमों को स्वीकार करने के लिए तैयार हूं।

एक समाधान यहां प्रकाशित किया गया

वर्कअराउंड इस तथ्य का फायदा उठाता है कि toolbox को एक बैश स्क्रिप्ट के रूप में कार्यान्वित किया जाता है जो पर्यावरण चर $HOME को उन सभी मामलों में संदर्भित करता है जहां /home/user के पथ को देखने की आवश्यकता होती है। इसलिए किसी विशेष कॉल के लिए पर्यावरण चर $HOME को toolbox से आपकी संपूर्ण होम निर्देशिका के अलावा मूल्यवान व्यक्तिगत फ़ाइलों से भरी एए निर्देशिका संभावित अविश्वसनीय कंटेनर के साथ साझा की जाती है।

उसके आधार पर, ऐसा प्रतीत होता है कि आप एक खाली निर्देशिका साझा कर सकते हैं जिसमें टूलबॉक्स को एक रैपर के साथ लॉन्च करके टूलबॉक्स कॉन्फ़िगरेशन शामिल है:

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

यदि इस स्क्रिप्ट को toolbox नाम दिया गया था और सिस्टम toolbox पहले आपके $PATH में डाल दिया गया था, तो ऐसा प्रतीत होता है कि यह इस चिंता का समाधान करेगा। यह समाधान परीक्षण नहीं किया गया है।

यह सुविधा अब tlbx फोर्क में काम कर रही है: https://gitlab.com/uppercat/tlbx/issues/3

मेरी भी यही समस्या है। मैंने इस उम्मीद के साथ सिल्वरब्लू स्थापित किया कि मैं कर पाऊंगा
सॉफ्टवेयर चलाएं जिस पर मैं पूरी तरह से भरोसा नहीं कर सकता, इस चिंता के बिना कि यह मेरे एसएसएच को चुरा लेता है
चाबियाँ और अन्य संवेदनशील जानकारी।

उम्म... यह भ्रामक लगता है। यदि आप एक उपयोगकर्ता के रूप में अविश्वसनीय सॉफ़्टवेयर चलाना चाहते हैं, तो फ़्लैटपैक पहले से ही संवेदनशील जानकारी खोने की आपकी चिंताओं को कम कर देता है। यदि आप अलग-थलग विकास वातावरण चाहते हैं, तो यह अलग बात है।

इसके अलावा, इनमें से कोई भी सिल्वरब्लू विशिष्ट नहीं है। समस्याएं दशकों से मौजूद हैं, और समाधान सिल्वरब्लू-विशिष्ट नहीं हैं - वे पारंपरिक पैकेज-आधारित ओएस पर भी काम करते हैं।

वर्कअराउंड इस तथ्य का फायदा उठाता है कि toolbox को बैश स्क्रिप्ट के रूप में लागू किया जाता है जो
उन सभी मामलों में पर्यावरण चर $HOME का संदर्भ देता है जहां /home/user . का पथ
ऊपर देखने की जरूरत है। तो किसी विशेष के लिए पर्यावरण चर $HOME सेट करके
toolbox कॉल करने से आपकी संपूर्ण होम निर्देशिका के अलावा अन्य निर्देशिका मूल्यवान हो जाती है
संभावित अविश्वसनीय कंटेनर के साथ साझा की जाने वाली व्यक्तिगत फ़ाइलें।

हाँ, यह एक साफ-सुथरी हैक है। :)

हालांकि, टूलबॉक्स प्रोजेक्ट का प्राथमिक उद्देश्य छवि-आधारित (विशेष रूप से OSTree-आधारित) ऑपरेटिंग सिस्टम पर विकास परिवेशों की एक विस्तृत विविधता को स्थापित करने में सक्षम बनाना है, जो उनके पैकेज-आधारित समकक्षों के लिए आवश्यक है। इन विकास परिवेशों को अधिक सुरक्षित बनाना निश्चित रूप से एक वैध इच्छा है, लेकिन यह कुछ ऐसा नहीं है जो तत्काल टू-डू सूची में है, क्योंकि समस्या नई नहीं है और हमेशा से मौजूद है।

इसके अलावा सिल्वरब्लू सुरक्षा के बारे में जरूरी नहीं है। मैं इसे ऑपरेटिंग सिस्टम की स्थिरता और मजबूती में सुधार के रूप में अधिक देखता हूं। हालाँकि, यह फ़्लैटपैक्स के उपयोग को प्रोत्साहित करता है, इसलिए इस अर्थ में यह अप्रत्यक्ष रूप से सुरक्षा में सुधार करता है।

इसलिए, पैकेज-आधारित लिनक्स वितरण के साथ फीचर समानता सुनिश्चित करने में मूल्य है, भले ही यह उनकी कुछ मौजूदा समस्याओं को बरकरार रखे। कुछ समस्याओं को हल करना और मौजूदा उपयोगकर्ता आधार के लिए समाधानों को सुलभ बनाना कुछ भी नहीं हल करने से बेहतर है। :)

मैं इस मुद्दे को बंद करने जा रहा हूं ताकि खुले मुद्दों की सूची नियंत्रण से बाहर न हो, और वर्तमान टू-डू सूची में मौजूद वस्तुओं को मोटे तौर पर प्रतिबिंबित करना जारी रखे। हालांकि, यह अभी भी भविष्य के संदर्भ के लिए आसपास रहेगा।

मैं सहमत हूं कि हमारे README.md को पढ़ना आसान होना चाहिए, हालांकि।

हम्म, मैं उस तर्क को नहीं समझता। सिर्फ इसलिए कि एक समस्या पुरानी है और हमेशा के लिए है, बस इसे हल न करें ?? यह एक अच्छा दृष्टिकोण नहीं है, आईएमएचओ।
और जैसा कि आप कहते हैं, फ्लैटपैक ऐसा करता है: यह कदम दर कदम सुरक्षा में सुधार करता है और अनुप्रयोगों को अलग करता है। उन्होंने यह भी नहीं कहा "हम्म, हमने हमेशा के लिए आरपीएम पैकेज के रूप में ऐप्स भेज दिए हैं, हमें इस समस्या का समाधान क्यों करना चाहिए?", उन्होंने इसे हल किया।

मुझे कोई कारण नहीं दिखता कि टूलबॉक्स को कम से कम होम डीआईआर को भी अलग क्यों नहीं करना चाहिए। इसलिए मुझे लगता है कि https://github.com/containers/toolbox/issues/348 में वैसे भी चर्चा जारी रखी जा सकती है।

मुझे लगता है कि टूलबॉक्स के योगदानकर्ता और अनुरक्षक इस धागे को विचार और परियोजना में किए गए कार्य पर कोसने के रूप में ले रहे हैं। मुझे लगता है कि इसे एक ऐसी विशेषता के रूप में लिया जाना चाहिए जो इस विचार से उत्साहित कई लोगों द्वारा आवश्यक है। मुझे ऐसी सुविधा पर काम करने का प्रतिरोध नहीं मिलता है जो आपको $HOME के ​​अलावा किसी अन्य कार्यशील निर्देशिका को माउंट करने की अनुमति देता है। यह एक ऐसी सुविधा है जो कार्यक्षमता और उपयोग के मामले में काफी सुधार कर सकती है जो अपनाने और रुचि में भी सुधार करेगी।

मैं वह था जिसने $HOME चर को #348 में बदलने का सुझाव दिया था। यह एक हैकी समाधान है क्योंकि यह समस्या का कारण बनता है जब आप अलग-अलग $ HOME निर्देशिकाओं वाले दो एकाधिक कंटेनरों के साथ काम करना चाहते हैं। मेरा डर यह भी है कि यह तब भी काम नहीं करेगा जब टूलबॉक्स को गो के साथ फिर से लिखा जाए।

बहुत से लोग इस सुविधा के लिए पूछ रहे हैं और कई लोगों के लिए टूलबॉक्स, आरपीएम-ओस्ट्री और सिल्वरब्लू को अपनाने के लिए यह प्रवेश में बाधा बन गया है। यहां तक ​​​​कि अगर यह सुरक्षा के बारे में नहीं है, तो यह एक ऐसी सुविधा है जो टूलबॉक्स के साथ काम करने के लिए बहुत सारी संभावनाएं खोलने जा रही है।

अगर मैं कर सकता हूं तो मैं इस मुद्दे पर मदद करने को तैयार हूं और मुझे लगता है कि दूसरे भी इसके लिए तैयार होंगे। मुझे आशा है कि यह सुविधा विवाद का विषय नहीं बनेगी और भविष्य के टूलबॉक्स रिलीज़ से बाहर हो जाएगी। मेरी राय में यह एकमात्र चीज है जो वर्तमान में इसमें गायब है। यह पिछले 10 मीटर छोड़ने के कारण मैराथन में डीएनएफ प्राप्त करने जैसा होगा। (जानबूझ का मजाक :) )

यह मेरे लिए एक डील-ब्रेकर था। मैंने टूलबॉक्स और सिल्वरब्लू को बाद में छोड़ दिया
इस दोष का पता लगाना।

सिर्फ इसलिए कि एक समस्या पुरानी है और हमेशा से रही है,
बस इसे हल मत करो ?? यह एक अच्छा दृष्टिकोण नहीं है, आईएमएचओ।

तत्काल टू-डू सूची में कुछ न होना वही बात नहीं है जो इसे हल नहीं करती है । प्राथमिकता जैसी कोई चीज होती

और जैसा कि आप कहते हैं, फ्लैटपैक ऐसा करता है: यह कदम दर कदम सुरक्षा में सुधार करता है और
अनुप्रयोगों को अलग करता है। उन्होंने यह भी नहीं कहा "हम्म, हमने ऐप्स को इस रूप में भेज दिया है
आरपीएम पैकेज हमेशा के लिए, हमें इस समस्या का समाधान क्यों करना चाहिए?", उन्होंने बस किया
इसे हल करो।

मुझे आपके द्वारा वे शब्द का उपयोग बहुत पसंद है।

ठीक है, अच्छा, तो अगर मैं इसे सही ढंग से व्याख्या करता हूं, तो यह अभी भी भविष्य के लिए एक विचार हो सकता है, न कि आपकी "तत्काल टू-डू सूची" पर? (हालांकि मुझे लगता है कि इसे लागू करना आसान है, खासकर यदि आप केवल एक कांटा से कुछ पैच चेरी-चुन सकते हैं ) *

यदि ऐसा है, तो शायद इस मुद्दे को खुला रखें और इसे "सहायता चाहता था" के रूप में टैग करें - हालांकि आपको वास्तव में सहायता की आवश्यकता नहीं है, पता नहीं ... आपको इसे लागू करने से क्या रोकता है? मुझे लगता है कि आपको बस इतना कहना है कि आप इस विषय पर पीआर स्वीकार करते हैं और इसे लागू किया जाएगा।
मुझे इससे कोई रोक नहीं रहा है - और आप अभी भी फीचर समता प्राप्त कर सकते हैं, जो भी हो ... यह वास्तव में केवल एक छोटी सी विशेषता है। :विचारधारा:

* हां, मैं देखता हूं और जानता हूं कि इसे अब गो में फिर से लिखा गया है, लेकिन शायद यह अभी भी मदद करता है - पता नहीं। कम से कम यह दर्शाता है कि इसे लागू करना आसान है।

यदि कोई प्रतिभागी https://gitlab.com/bkhl/etui पर मेरे प्रोटोटाइप की जांच करना चाहता है और प्रतिक्रिया देना चाहता है, तो इस मुद्दे को यहाँ थोड़ा हाईजैक करना

जब आप अधिक सख्ती से निहित विकास कंटेनर चाहते हैं तो यह टूलबॉक्स के विकल्प के रूप में होता है।

@bkhl धन्यवाद! बुकमार्क किया गया।