Libseccomp: RFE: "अधिकतम कर्नेल संस्करण" का समर्थन करें

+1
इससे सुरक्षा मुद्दों को कम करने के लिए काली सूची को उपयोगी बनाने में मदद मिलेगी।

@nmav स्पष्ट होने के लिए, यह RFE आंतरिक syscall तालिकाओं में जानकारी जोड़ने के लिए है जब syscall को पहली बार Linux कर्नेल में पेश किया गया था, न कि यह निर्धारित करने के लिए तर्क जोड़ने के लिए कि वर्तमान चल रहा कर्नेल किसी दिए गए syscall का समर्थन करता है या नहीं। हालाँकि, यदि आप एक syscall को ब्लॉक करने का प्रयास कर रहे हैं, तो आप libseccomp के साथ ऐसा कर सकते हैं, भले ही यह किसी विशेष आर्क/ABI और कर्नेल संस्करण पर समर्थित हो, libseccomp आपके लिए सही काम करेगा।

यह RFE लगभग पाँच वर्ष पुराना है, और @cgwalters के साथ एक एकल चर्चा के बाहर मैंने ऐसी सुविधा में बहुत अधिक रुचि नहीं देखी या सुनी है। कई अन्य खुले मुद्दों के साथ, अधिकांश उच्च प्राथमिकता के साथ, यह स्पष्ट नहीं है कि हम इस पर कब काम करेंगे, या यहां तक ​​​​कि अगर ऐसी चीज एक उपयोगी अतिरिक्त होगी।

@cgwalters और @drakenclimber 2020 में इस मुद्दे के बारे में आप क्या सोचते हैं? मैं इसे WONTFIX के रूप में बंद करने का लुत्फ उठा रहा हूं, लेकिन इससे पहले कि हम यह कदम उठाएं, मैं कुछ टिप्पणियां और प्रतिक्रिया प्राप्त करना चाहता हूं।

@cgwalters और @drakenclimber 2020 में इस मुद्दे के बारे में आप क्या सोचते हैं? मैं इसे WONTFIX के रूप में बंद करने का लुत्फ उठा रहा हूं, लेकिन इससे पहले कि हम यह कदम उठाएं, मैं कुछ टिप्पणियां और प्रतिक्रिया प्राप्त करना चाहता हूं।

ईमानदारी से मुझे लगता है कि यह वास्तव में एक अच्छा विचार है। मेरे कई इन-हाउस ग्राहक इस सटीक कारण से अनुमति सूची का उपयोग कर रहे हैं। यदि वे एक इनकार सूची का उपयोग करते हैं और कर्नेल में एक नया सिस्कल जोड़ा जाता है, तो वह सिस्कल हमले का एक और तरीका होगा।

आइए इसे थोड़ी देर के लिए खुला छोड़ दें। मैं Oracle के भीतर पूछूंगा और देखूंगा कि क्या कोई ग्राहक इस सुविधा में पर्याप्त रुचि रखता है ताकि मैं इसे उठा सकूं। लेकिन @cgwalters (या उस मामले के लिए कोई और) का पूरी तरह से स्वागत है अगर उनके पास समय और रुचि है :)।

ठीक है, जब तक रुचि है, मुझे इसे खुला रखने में कोई समस्या नहीं है।

मुझे अभी भी लगता है कि यह उपयोगी होगा!

ऐसा लगता है कि अंक #286 इस काम को आगे बढ़ाने में मदद करने के लिए ठोस मुद्दा है ... भले ही लगभग पांच साल हो गए हों;)

मुझे लगता है कि इस दिशा में पहला कदम syscalls.csv फ़ाइल में एक नया फ़ील्ड जोड़ना है जो इंगित करता है कि syscall को पहली बार कब पेश किया गया था। यह काम का एक अच्छा हिस्सा होने जा रहा है क्योंकि वर्तमान में हमारे पास ~ 469 सिस्को परिभाषित (!) हालांकि, हम मौजूदा सिस्को के लिए इस काम को "अपरिभाषित" मान के साथ परिशोधित कर सकते हैं जिसे हम समय के भोर में बनाए जा रहे सिस्कल के रूप में मानेंगे। बेशक syscalls.csv तालिका में सभी नए परिवर्धन को कर्नेल संस्करण के साथ जोड़ने की आवश्यकता होगी।

कुछ और त्वरित विचार:

• syscall.csv प्रारूप

#syscall (v5.8.0-rc5 2020-07-14),kver_min,x86,x86_64,...
accept,<version>,PNR,43,...

... जहां <version> कुछ ऐसा हो सकता है जैसे "5_8", "UNDEF", या इसी तरह का।

• संस्करण टोकन

enum kernel_version {
    KV_UNDEF = 0,
    KV_1_0,
    KV_1_1,
    KV_1_3,
    KV_2_0,
    ...
    KV_5_8,
    _KV_MAX,
};

क्या कर्नेल संस्करण ट्रैक करने के लिए सही चीज़ है? क्या यह गारंटी है कि नए syscalls को कम संस्करण संख्या के साथ स्थिर कर्नेल शाखाओं जैसे बैकपोर्ट नहीं किया जाता है?

Red Hat सभी प्रकार की चीजों को उनके कर्नेल में बैकपोर्ट करेगा, इसलिए नहीं।

यदि RedHat किसी पुराने कर्नेल संस्करण में syscall को बैकपोर्ट करता है, तो वे मिलान करने के लिए libseccomp के अपने संस्करण को पैच भी कर सकते हैं। हालांकि निष्पक्ष होने के लिए यह कुछ उपयोग-मामलों के लिए अधिक मायने रखता है लेकिन # 286 को ठीक करने के दृष्टिकोण के रूप में मुझे लगता है कि यह काफी व्यावहारिक है। दूसरी समस्या यह है कि मुझे यकीन नहीं है कि कोई बेहतर तरीका है - गैर-लगातार क्रम में syscalls जोड़ा जा सकता है (उदाहरण के लिए openat2 close_range से पहले जोड़ा गया था - हालांकि यह उदाहरण दयालु है मेरी गलती का)।

यदि RedHat किसी पुराने कर्नेल संस्करण में syscall को बैकपोर्ट करता है, तो वे मिलान करने के लिए libseccomp के अपने संस्करण को पैच भी कर सकते हैं।

हाँ बिल्कुल। अपस्ट्रीम libseccomp प्रोजेक्ट का विभिन्न एंटरप्राइज़ Linux वितरणों पर कोई नियंत्रण नहीं है और यदि वे वितरण अपस्ट्रीम प्रोजेक्ट्स (या तो Linux कर्नेल या libseccomp) से विचलित होने का निर्णय लेते हैं, तो वे समर्थन के लिए स्वयं हैं। जबकि हम मदद करने के लिए अपनी पूरी कोशिश करेंगे, हम इन उद्यम वितरणों के पक्ष में अपस्ट्रीम परियोजना को उनके स्वयं के समर्थन और इंजीनियरिंग कर्मचारियों के साथ बलिदान नहीं कर सकते हैं।

संदर्भ बिंदु के रूप में, syscalls(2) मैनपेज में कुछ ऐतिहासिक जानकारी होती है जब विभिन्न सिस्को को कर्नेल में पेश किया गया था:

• https://www.mankier.com/2/syscalls

मैं प्रत्येक syscall के लिए एक संस्करण संख्या का पता लगाने के लिए syscall spelunking कर सकता हूं - एकमात्र सवाल यह है कि क्या हमारे पास संस्करण संख्या प्रति-आर्किटेक्चर होनी चाहिए क्योंकि मुझे पूरा यकीन है कि अलग-अलग रिलीज में अलग-अलग आर्किटेक्चर में कुछ सिस्कल जोड़े गए थे।

... एकमात्र सवाल यह है कि क्या हमारे पास संस्करण संख्या प्रति-आर्किटेक्चर होनी चाहिए क्योंकि मुझे पूरा यकीन है कि अलग-अलग रिलीज में अलग-अलग आर्किटेक्चर में कुछ सिस्को जोड़े गए थे।

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

इस @cyphar पर आप जो भी मदद प्रदान कर सकते हैं, उसकी बहुत सराहना की जाएगी।