টার্মিনালে রুট, SELinux-এর অধীনে প্রত্যাখ্যাত: কেন হুক ব্যর্থ হয়

আপনি রুট হিসেবে up স্ক্রিপ্ট চালান, এটি সম্পন্ন হয়, এবং সার্ভিস যখন একই স্ক্রিপ্ট আহ্বান করে তখন তা ব্যর্থ হয়। ফাইলের অনুমতিতে কিছুই বদলায়নি, তাই স্বাভাবিক পরবর্তী পদক্ষেপ হলো সেগুলো আবার শিথিল করা, যা কিছুই ঠিক করে না। SELinux হোস্টে নির্ণায়ক বিষয়টি প্রায়ই প্রক্রিয়াটি কে তা নয়, বরং এটি কোন ডোমেইনে চলে, এবং সীমাবদ্ধ ডোমেইনের ভিতরে রুটও সীমাবদ্ধ থাকে।

একই কমান্ড, দুটি ভিন্ন নিরাপত্তা ডোমেইন

টাইপ এনফোর্সমেন্ট সোর্স ডোমেইন, টার্গেট লেবেল এবং অনুরোধকৃত অপারেশন একসাথে মূল্যায়ন করে। আপনার টার্মিনাল সেশন একটি অসীমাবদ্ধ বা প্রশাসনিক ডোমেইনে চলে, আর ডেমনটি তার ইউনিটে বরাদ্দকৃত ডোমেইনে চলে। তাই অভিন্ন কমান্ড ভিন্ন সিদ্ধান্ত দেয়, এবং এই পার্থক্য নীতির বাগ নয়, বরং নকশারই ফল।

এই কারণেই দুটি রান তুলনা করা কেবল তখনই কাজে লাগে যখন আপনি তাদের প্রেক্ষাপট তুলনা করেন। শেল এবং হুক — উভয় জায়গা থেকেই একই কমান্ড চালান; শেল সংস্করণটি প্রমাণ করে বাইনারিটি আছে এবং আর্গুমেন্টগুলো ঠিক, কিন্তু সার্ভিসটি এটি চালানোর অনুমতি পেয়েছে কি না সে সম্পর্কে কিছুই প্রমাণ করে না। দুইভাবেই চালান এবং কেবল এক্সিট কোড নয়, ডোমেইনগুলো তুলনা করুন। ওই তুলনাই একটি অস্পষ্ট অনুমতি-অভিযোগকে এক ডোমেইন ও এক লেবেল নিয়ে নির্দিষ্ট প্রশ্নে বদলে দেয়।

এই ত্রুটির চিরাচরিত রূপ হলো এমন একটি হেল্পার যা একটি বাহ্যিক টুল আহ্বান করে। হুক নিজে অনুমোদিত হতে পারে, অথচ যে টুলটি এটি আহ্বান করে তার গায়ে এমন লেবেল থাকতে পারে যা সার্ভিস ডোমেইন চালাতে পারে না, বা এমন ডিরেক্টরিতে লেখে যার লেবেল তা নিষেধ করে।

হুক ত্রুটির পাশে AVC রেকর্ড পড়ুন

একটি AVC প্রত্যাখ্যান সেই ক্ষেত্রগুলোর নাম দেয় যা মামলা নির্ধারণ করে: প্রক্রিয়ার সোর্স প্রেক্ষাপট, অবজেক্টের টার্গেট প্রেক্ষাপট, অবজেক্ট ক্লাস এবং যে নির্দিষ্ট অনুমতি প্রত্যাখ্যাত হয়েছে। তত্ত্ব তৈরির আগে চারটিই পড়ুন, কারণ এক্সিকিউটে প্রত্যাখ্যান আর রাইটে প্রত্যাখ্যানের মেরামত সম্পূর্ণ ভিন্ন।

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

সোর্স প্রেক্ষাপটের সার্ভিসটি যে ডোমেইনে সত্যিই চলে তার সাথে মিল থাকা উচিত, আর টার্গেট প্রেক্ষাপটের অপারেশনটি যে ফাইল বা ডিরেক্টরি স্পর্শ করেছে তার লেবেলের সাথে মিল থাকা উচিত। এর যেকোনোটি যদি আপনার অনুসরণ করা ত্রুটির সাথে না মেলে, তবে আপনি ভিন্ন একটি ঘটনা পড়ছেন।

রেকর্ডের পাশে নীতির সংস্করণ এবং সঠিক এক্সিকিউটেবল পথ লক্ষ্য করুন। একটি ডিস্ট্রিবিউশনের নীতিতে যে ডোমেইন নাম দেখা যায় তা ওই ইনস্টলেশন সম্পর্কে প্রমাণ, অন্য কোনো বিল্ড একই নিয়ম সরবরাহ করে এমন নিশ্চয়তা নয়। এই প্রেক্ষাপটই অন্য কাউকে তার নিজের হোস্টে আপনার সিদ্ধান্ত পুনরুৎপাদন করতে দেয়। এটি ছাড়া রেকর্ডটি প্রমাণের বদলে উপাখ্যানের মতো পড়া হয়।

লেবেল, কনফিগারেশন নাকি নীতি: তিনটি মেরামত

প্রথম মেরামত হলো এমন লেবেল যা ফাইলের ইনস্টল করা অবস্থানের সাথে মেলে না। cp দিয়ে জায়গামতো কপি করা বা এডিটরে লেখা স্ক্রিপ্ট এমন ডিফল্ট লেবেল বহন করতে পারে যা সার্ভিস ডোমেইন ব্যবহার করতে পারে না, এবং প্রত্যাশিত প্রেক্ষাপট পুনরুদ্ধার করলে নীতিতে হাত না দিয়েই তা ঠিক হয়ে যায়।

দ্বিতীয়টি কনফিগারেশন। ডিস্ট্রিবিউশন হয়তো অপারেশনটি চালানোর একটি সমর্থিত উপায়, হেল্পারের জন্য একটি নথিভুক্ত ডিরেক্টরি, বা এমন একটি হালনাগাদ নীতি প্যাকেজ দিতে পারে যা এটি ইতিমধ্যেই অনুমোদন করে। আপনার লেআউটকে সমর্থিত একটিতে বদলানো নীতি লেখার চেয়ে সস্তা এবং হালনাগাদে টিকে থাকে।

তৃতীয়টি সত্যিই অনুপস্থিত একটি নিয়ম, এবং এটি শেষ উপায় হওয়া উচিত। অডিট টুলিং দিয়ে একটি প্রার্থী তৈরি করুন, এটি আসলে কী অনুমোদন করে তা পড়ুন, আপনার পর্যবেক্ষণ করা অপারেশন ও ডোমেইনে সেটি সংকুচিত করুন, এবং প্রোডাকশনের কাছে যাওয়ার আগে অন্য কাউকে দিয়ে পর্যালোচনা করান।

কেন একটি পুরোনো allow মডিউল উত্তর নয়

এই ত্রুটির জন্য অনুসন্ধান ফলাফল প্রস্তুত মডিউলে ভরা, প্রায়ই এমন একটি টুলের জন্য যা হুক আর আহ্বান করে না। একটি ইনস্টল করলে এমন অনুমতি পাওয়া যায় যার সঙ্গে আপনার প্রত্যাখ্যানের কোনো সম্পর্কই নাও থাকতে পারে, এবং এটি আসল অমিলটিকে জায়গায় রেখেই একটি স্থায়ী ফাঁক যোগ করে।

এটি পরবর্তী ব্যর্থতাটিও লুকায়। যে মডিউল বিস্তৃত শ্রেণির অপারেশন অনুমোদন করে তা এই ত্রুটিটি মুছে দেবে এবং পরেরটিকে এমন কিছুতে পরিণত করবে যা আরোপ করা অনেক কঠিন। পরে মডিউলটি সরানোও এমন পরিবর্তন যা কেউ সময়সূচিতে রাখতে চায় না, তাই শর্টকাটটি স্থায়ী হয়ে যাওয়ার প্রবণতা রাখে।

সুশৃঙ্খল তুলনাটি হলো আপনি যে প্রত্যাখ্যানটি পড়তে পারেন এবং আপনি যে পরিবর্তন প্রস্তাব করছেন তার মধ্যে। Red Hat-এর SELinux সমস্যা সমাধানের নির্দেশিকা ঠিক এই কারণেই লেবেলিং ও কনফিগারেশন যাচাইকে উৎপন্ন নীতির আগে রাখে। যদি রেকর্ডে সংশ্লিষ্ট কোনো প্রত্যাখ্যান না থাকে, তবে SELinux সম্ভবত আপনার সমস্যা নয়, এবং পথ, স্যান্ডবক্স বা অনুমতির সমস্যাগুলো এখনও খোলা।