সম্প্রতি, কসমোপলিটান সি স্ট্যান্ডার্ড লাইব্রেরি এবং রেডবিন প্ল্যাটফর্মের নির্মাতা লিনাক্সের জন্য pledge() আইসোলেশন মেকানিজম বাস্তবায়নের ঘোষণা দিয়েছেন।
মূলত ওপেনবিএসডি প্রজেক্ট দ্বারা তৈরি , প্লেজ (pledge) আপনাকে অ্যাপ্লিকেশনগুলিকে অব্যবহৃত সিস্টেম কল অ্যাক্সেস করা থেকে বেছে বেছে বিরত রাখতে দেয় (অ্যাপ্লিকেশনটির জন্য সিস্টেম কলের একটি হোয়াইটলিস্ট তৈরি করে এবং অন্যান্য কল নিষিদ্ধ করে)। লিনাক্সে উপলব্ধ সেকম্প (seccomp)-এর মতো সিস্টেম কল অ্যাক্সেস কন্ট্রোল মেকানিজমগুলির থেকে ভিন্ন, প্লেজকে একেবারে গোড়া থেকেই যতটা সম্ভব ব্যবহারকারী-বান্ধব করে ডিজাইন করা হয়েছে।
ওপেনবিএসডি বেস এনভায়রনমেন্টে সিস্ট্রেস মেকানিজম ব্যবহার করে অ্যাপ্লিকেশনগুলিকে বিচ্ছিন্ন করার ব্যর্থ উদ্যোগ প্রমাণ করেছে যে পৃথক সিস্টেম কলের স্তরে বিচ্ছিন্নতা অত্যন্ত জটিল এবং সময়সাপেক্ষ।
এর বিকল্প হিসেবে প্লেজ (pledge) প্রস্তাব করা হয়েছিল, যা প্রিপেয়ার্ড অ্যাক্সেস ক্লাসগুলোর বিশদ বিবরণ ও পরিবর্তন না করেই আইসোলেশন রুল তৈরি করার সুযোগ দিত ।
উদাহরণস্বরূপ, দেওয়া ক্লাসগুলি হল stdio (ইনপুট/আউটপুট), rpath (শুধু ফাইলগুলি পড়ুন), wpath (ফাইলগুলি লিখুন), cpath (ফাইলগুলি তৈরি করুন), tmppath (অস্থায়ী ফাইলগুলির সাথে কাজ করুন), inet (সকেট নেটওয়ার্ক), ইউনিক্স (ইউনিক্স সকেটগুলি) ), dns (DNS রেজোলিউশন), getpw (ইউজার ডাটাবেসে পড়ার অ্যাক্সেস), ioctl (ioctl কল), proc (প্রসেস কন্ট্রোল), exec (স্টার্টআপ প্রসেস), এবং আইডি (অনুমতি নিয়ন্ত্রণ)।
সিস্টেম কল নিয়ে কাজ করার নিয়মগুলো অ্যানোটেশন আকারে নির্দিষ্ট করা থাকে, যেগুলোতে অনুমোদিত সিস্টেম কল ক্লাসের একটি তালিকা এবং অ্যাক্সেসের অনুমতিপ্রাপ্ত ফাইল পাথের একটি অ্যারে অন্তর্ভুক্ত থাকে। পরিবর্তিত অ্যাপ্লিকেশনটি কম্পাইল ও রান করার পর, কার্নেল নির্দিষ্ট নিয়মগুলো মেনে চলা হচ্ছে কি না, তা পর্যবেক্ষণ করার দায়িত্ব গ্রহণ করে।
আলাদাভাবে, ফ্রিবিএসডি-র জন্য অঙ্গীকার বাস্তবায়ন তৈরি করা হচ্ছে, যা তাদের কোডে পরিবর্তন না করেই অ্যাপ্লিকেশনগুলিকে আলাদা করার ক্ষমতা দ্বারা আলাদা করা হয়, যখন ওপেনবিএসডি-তে প্রতিশ্রুতি কলের লক্ষ্য হল বেস পরিবেশের সাথে কঠোর সংহতকরণ এবং কোডে টীকা যোগ করা। প্রতিটির
অঙ্গীকার হল নিষিদ্ধ ফলের মত যা আমরা সকলেই কামনা করি যখন বস বলেন আমাদের লিনাক্সের মত জিনিস ব্যবহার করা উচিত। কেন যে ব্যাপার? কারণ প্রতিশ্রুতি() আসলে নিরাপত্তাকে বোধগম্য করে তোলে। লিনাক্সে কখনোই এমন নিরাপত্তার স্তর ছিল না যা নিছক মানুষ বুঝতে পারে।
লিনাক্স প্লেজ পোর্টের ডেভেলপাররা ফ্রিবিএসডি-র পথ অনুসরণ করে , কোডে কোনো পরিবর্তন না করে, pledge.com থেকে একটি অতিরিক্ত ইউটিলিটি তৈরি করেছেন যা আপনার অ্যাপ্লিকেশন কোড পরিবর্তন না করেই সীমাবদ্ধতা আরোপ করার সুযোগ দেয়। উদাহরণস্বরূপ, শুধুমাত্র stdio, rpath, inet, এবং threadstdio সিস্টেম কল ক্লাসগুলিতে অ্যাক্সেস সহ curl ইউটিলিটিটি চালাতে, কেবল `./pledge.com -p 'stdio rpath inet thread' curl http://example.com` কমান্ডটি চালান।
এই ইউটিলিটিটি RHEL6 থেকে শুরু করে পরবর্তী সকল লিনাক্স ডিস্ট্রিবিউশনে কাজ করে এবং এর জন্য রুট অ্যাক্সেসের প্রয়োজন হয় না। এছাড়াও, কসমোপলিটান লাইব্রেরির উপর ভিত্তি করে, সি প্রোগ্রাম কোডে বিধিনিষেধ পরিচালনার জন্য একটি এপিআই (API) প্রদান করা হয়েছে, যা অন্যান্য কাজের পাশাপাশি, নির্দিষ্ট অ্যাপ্লিকেশন ফাংশনগুলিতে অ্যাক্সেস বেছে বেছে সীমাবদ্ধ করার জন্য এনক্লেভ (enclave) তৈরির সুযোগ দেয়।
অতীতে কিছু ডেভেলপার আছে যারা এই চেষ্টা করেছে। আমি নাম বলতে যাচ্ছি না, কারণ এই প্রকল্পগুলির বেশিরভাগই শেষ হয়নি। যখন এটি SECOMP আসে, অনলাইন টিউটোরিয়ালগুলি কেবল ব্যাখ্যা করে যে কীভাবে সিস্টেম কলগুলিকে হোয়াইটলিস্ট করতে হয়, তাই বেশিরভাগ লোক কীভাবে আর্গুমেন্ট ফিল্টার করতে হয় তা বের করার আগে আগ্রহ হারিয়ে ফেলে। যে প্রকল্পগুলি এগিয়ে গেছে সেগুলিরও নজরদারি ছিল যেমন সেটুইড/সেটগিড/স্টিকি বিটগুলি পরিবর্তন করার অনুমতি দেওয়া। অতএব, বর্তমান বিকল্পগুলির কোনটি ব্যবহার করা উচিত নয়। আমি মনে করি এই প্রয়াস আমাদের আগের চেয়ে অনেক বেশি প্রতিজ্ঞা() করার কাছাকাছি নিয়ে এসেছে।
বাস্তবায়নের জন্য কার্নেল পরিবর্তনের প্রয়োজন নেই: ইউটিলিটি সীমাবদ্ধতাগুলি SECOMP BPF নিয়মে অনুবাদ করা হয় এবং লিনাক্সের নেটিভ সিস্টেম কল আইসোলেশন মেকানিজম ব্যবহার করে প্রক্রিয়া করা হয়। উদাহরণস্বরূপ, কল করার প্রতিশ্রুতি("stdio rpath", 0) একটি BPF ফিল্টারে রূপান্তরিত হবে
অবশেষে, আপনি যদি আরও জানতে আগ্রহী হন, তাহলে নিচের লিঙ্কে বিস্তারিত তথ্য পেয়ে যাবেন ।