VPN সার্টিফিকেট সরানো কেন এর SELinux লেবেল ভেঙে দেয়

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

নাম বদল আসলে একটি লেবেলের সঙ্গে কী করে

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

কপি করা ভিন্নভাবে আচরণ করে। একটি কপি গন্তব্য ডিরেক্টরিতে নতুন inode তৈরি করে, আর নীতি সেই ডিরেক্টরির টাইপ থেকে একটি প্রসঙ্গ নির্ধারণ করে, তাই কপি করা সার্টিফিকেট সাধারণত সঠিকভাবে লেবেল পায়, অথচ সরানোটি ভুলই থাকে। এই একক পার্থক্যই এই ধরনের টিকিটে বেশিরভাগ বিভ্রান্তির ব্যাখ্যা দেয়।

ফাইলসিস্টেম-পারাপার সরানো কপি-অর্থবিজ্ঞানে ফিরে যায়, তাই একই কমান্ড দুটি মেশিনে ভিন্নভাবে আচরণ করতে পারে, নির্ভর করে /etc নিজস্ব ভলিউমে আছে কি না তার উপর। টুলটি অবিশ্বস্ত বলে সিদ্ধান্তে পৌঁছানোর আগে এটি যাচাই করুন। মাউন্ট টেবিলে একবার চোখ বুলালেই বোঝা যায় আপনি কোন ধরনের সরানো করেছেন।

বর্তমান লেবেল প্রত্যাশিতটির সঙ্গে মিলিয়ে পড়ুন

তিনটি শুধু-পাঠযোগ্য কমান্ড কোনো কিছু না বদলেই প্রশ্নের উত্তর দেয়। প্রথমটি দেখায় ফাইলটির এখন কী আছে, দ্বিতীয়টি জানায় নীতিটি ঠিক ওই পথের জন্য কী প্রত্যাশা করে, আর তৃতীয়টি ডিরেক্টরির অধীনে এমন প্রতিটি ফাইল তালিকাভুক্ত করে যার লেবেল আলাদা।

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

তারপর পার্থক্যটিকে প্রকৃত প্রত্যাখ্যানের সঙ্গে মিলিয়ে দেখুন। অমিল একটি ভুল লেবেলের প্রমাণ, এই প্রমাণ নয় যে সেবাটি এর কারণে ব্যর্থ হয়েছে, এবং লগে সংশ্লিষ্ট প্রত্যাখ্যান ছাড়া প্রয়োগ করা সংশোধন অতিরিক্ত ধাপসহ একটি অনুমান।

ব্যতিক্রম উদ্ভাবনের বদলে ম্যাপিং পুনরুদ্ধার করুন

স্ট্যান্ডার্ড অবস্থানের জন্য নীতি ইতিমধ্যেই পথটি ম্যাপ করে রেখেছে, তাই restorecon সেটি প্রয়োগ করে আর কাজ শেষ। পরিধিটি আপনি যে ডিরেক্টরি মেরামত করছেন তার মধ্যেই রাখুন; পুরো ফাইলসিস্টেম নতুন করে লেবেল করা ধীর, ব্যাঘাতমূলক, আর তা মূল ভুলটিকে খুব বড় পরিবর্তনের নিচে চাপা দেয়।

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

কেন chcon সমাধান নয়

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

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

যখন লেবেল ঠিক থাকে আর অ্যাক্সেস তবুও ব্যর্থ হয়

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

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

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