OpenVPN-এর user ড্রপের উপরে systemd হার্ডেনিং স্তূপ করবেন না

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

দুই মডেল, পরিবর্তনের এক মালিক

প্রথম মডেলটি ডেমনের। কমিউনিটি OpenVPN-এর user ও group অপশন টানেল ও চাবি তৈরি হওয়ার পরে পরিচয় বদলায়, আর persist-key সহ persist-tun সেই সম্পদগুলোকে পরে ব্যবহারযোগ্য রাখে।

দ্বিতীয় মডেলটি সার্ভিস ম্যানেজারের। systemd-এর User= বা Group= সেটিং প্রক্রিয়াটি কোন পরিচয়ে শুরু হবে তা ঠিক করে, আর সক্ষমতা-নির্দেশনা ঠিক করে এটি কী ধারণ করতে পারবে। মডেল দুটির মধ্যে বেছে নেওয়া নিরাপত্তার প্রশ্ন হওয়ার আগেই প্যাকেজিংয়ের প্রশ্ন, আর প্যাকেজ রক্ষণকারী ইতিমধ্যে তার উত্তর দিয়েছেন। আপনার কাজ তৃতীয় কোনো বিকল্প উদ্ভাবন নয়, সেই উত্তরটিই খুঁজে বের করা।

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

পরিচয় কোথায় বদলায় তা ঠিক করুন

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

কিছু সম্পাদনা করার আগে ইনস্টল করা প্যাকেজটি আসলে কী দেয় তা পড়ুন, তার drop-in ডিরেক্টরিসহ। কিছু ইউনিট ইচ্ছাকৃতভাবে ডেমনের নিজস্ব ড্রপ বাদ দেয়, কারণ ম্যানেজার সেটি আগেই সামলায়, আর কিছু ইউনিট আরম্ভের পরের পরিবর্তনের জন্য ওই অপশনগুলোর উপর নির্ভর করে। কোন মডেল আপনি উত্তরাধিকার সূত্রে পেয়েছেন না জেনে যেকোনোটি সরানোই একটি চালু সার্ভিস বন্ধ হয়ে যাওয়ার উপায়।

নির্বাচিত মডেলটি এক লাইনে লিখুন: ম্যানেজার-মালিকানাধীন না ডেমন-মালিকানাধীন। পরের প্রতিটি নির্দেশকে ওই বাক্যের সঙ্গে সামঞ্জস্যপূর্ণ হতে হবে, আর মিশ্র ইউনিটকে সমঝোতা নয়, বরং ত্রুটি হিসেবে গণ্য করতে হবে।

সক্ষমতা সীমা, অনুদান নয়

সক্ষমতা-সীমা সেট বলে একটি প্রক্রিয়া সর্বাধিক কী ধারণ করতে পারে। এটি একটি ছাদ, আর সেখানে সক্ষমতা তালিকাভুক্ত করলে নিজে থেকে কিছুই দেওয়া হয় না, তাই উদার সীমা-সেট থাকা ইউনিটও টানেল তৈরি করতে ব্যর্থ হতে পারে।

যেটি সত্যিই একটি সক্ষমতাকে সার্ভিসের পরিবেষ্টিত সেটে বসায় তা হলো AmbientCapabilities=। systemd সম্পাদন রেফারেন্স দুটি নির্দেশকে আলাদাভাবে নথিভুক্ত করে, আর এই পার্থক্যই অনলাইনে সক্ষমতা নিয়ে বিভ্রান্তিকর পরামর্শের বেশিরভাগ ব্যাখ্যা দেয়।

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

জীবনচক্র জুড়ে কর্তৃত্ব ম্যাপ করুন

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

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

ভাগ করা নয়, নিবেদিত অ্যাকাউন্ট ব্যবহার করুন। OpenVPN-এর মূল প্রকল্প nobodyকে সাধারণ উদাহরণ হিসেবে ব্যবহার করার অভ্যাসের বিরুদ্ধে সতর্ক করে, কারণ হোস্টের অন্য সার্ভিসগুলো ইতিমধ্যে ওই অ্যাকাউন্টে চলতে পারে এবং আপনার ধারণা করা বিচ্ছিন্নতা সেখানে নেই।

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

পরিকল্পনা লিখে রাখুন এবং পুনরুদ্ধারের প্রবেশাধিকার রাখুন

স্থাপনার নথিতে ম্যানেজার, শুরুর পরিচয়, কাঙ্ক্ষিত স্থিতিশীল পরিচয় এবং প্রতিটি অনুমতি তার প্রয়োজনীয় কাজের সঙ্গে নাম উল্লেখ করা উচিত। ওই নথিই পরের পরিবর্তনটিকে পরীক্ষামূলক নয়, পর্যালোচনাযোগ্য করে তোলে।

সম্পাদনার সময় কনসোল প্রবেশাধিকার খোলা রাখুন, কারণ শুরুতেই ব্যর্থ হওয়া ইউনিট দূর থেকে মেরামত করা কঠিন। পরিবর্তনটি সম্পূর্ণ বলার আগে রিস্টার্ট ও সম্পূর্ণ রিবুট পরীক্ষা করুন। রিস্টার্ট উতরে যাওয়া ইউনিট নেটওয়ার্ক চালু হওয়ার আগেই ব্যর্থ হতে পারে।

সফলতা হলো একটি বোঝা সর্বনিম্ন-কর্তৃত্বের জীবনচক্র, এমন প্রক্রিয়া নয় যা কাকতালীয়ভাবে অ-রুট নামে চলছে।