Service কি root হিসেবে চালানো উচিত?

কেন সবকিছু root হিসেবে চালানো উচিত নয়

Root মেশিনে যেকোনো কিছু করতে পারে: প্রতিটি ফাইল পড়া, যেকোনো সেটিংস পরিবর্তন করা, এমনকি পুরো সিস্টেম মুছে ফেলা। আপনি যখন কোনো service root হিসেবে চালান, তখন আপনি সেই service-কে সমস্ত ক্ষমতা দিয়ে দেন। যদি ওই service-এ কোনো bug থাকে যা আক্রমণকারী ব্যবহার করতে পারে, তবে তারা শুধু service-টি পায় না, তারা root পেয়ে যায়; আর root মানে হলো পুরো সার্ভার। একটি unprivileged user হিসেবে চালানো ক্ষতিকে সীমাবদ্ধ করে দেয়। একটি limited account হিসেবে চলা service-এর bug আক্রমণকারীকে কেবল সেই account-এর অ্যাক্সেসটুকু দেয়, যা মূলত খুব সামান্য হওয়া উচিত।

এটি হলো least privilege নীতি: সিস্টেমের প্রতিটি অংশকে তার কাজের জন্য ঠিক যতটুকু অ্যাক্সেস প্রয়োজন তা দেওয়া, তার বেশি নয়। কোনো compromise-এর blast radius বা ক্ষতির পরিধি সীমিত করার জন্য এটি সবচেয়ে কার্যকর অভ্যাস, এবং একটি আধুনিক সার্ভারে এটি প্রয়োগ করতে আপনার প্রায় কোনো খরচই নেই।

প্রতিটি service-এর জন্য একটি ডেডিকেটেড account

প্রথাগত পদ্ধতি হলো প্রতিটি service-এর জন্য একটি আলাদা system user তৈরি করা, যা শুধুমাত্র ওই service-এর ফাইলগুলোর মালিক হবে এবং লগ-ইন করতে পারবে না। একটি web app-এর জন্য system account দেখতে এমন হতে পারে:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

প্রতিটি flag গুরুত্বপূর্ণ। --system এটিকে একটি service account হিসেবে চিহ্নিত করে, কোনো মানুষের লগ-ইন হিসেবে নয়। --no-create-home অপ্রয়োজনীয় home directory এড়িয়ে চলে। --shell /usr/sbin/nologin মানে হলো আক্রমণকারী কোনোভাবে অ্যাকাউন্টটি পেয়ে গেলেও, তারা এটি দিয়ে কোনো shell খুলতে পারবে না। অ্যাকাউন্টটি শুধুমাত্র একটি process এবং তার ফাইলগুলোর মালিক হওয়ার জন্য বিদ্যমান।

এরপর সেই user-কে কেবল তার প্রয়োজনীয় ফাইলগুলো দিন, তার বেশি নয়:

sudo chown -R appsvc:appsvc /opt/myapp

এখন service-টি তার নিজস্ব directory পড়া এবং লিখতে পারবে এবং ডিস্কের অন্য কোথাও তার কোনো প্রয়োজন নেই। যদি এটি কখনো exploit করা হয়, তবে আক্রমণকারী যে ফাইলগুলো পরিবর্তন করতে পারবে তা /opt/myapp এর মধ্যে সীমাবদ্ধ থাকবে; অ্যাকাউন্টটি এখনও world-readable যেকোনো কিছু পড়তে পারবে, কিন্তু সিস্টেমের বাকি অংশ পরিবর্তন করতে পারবে না।

systemd দিয়ে এটিকে সেই user হিসেবে চালানো

অ্যাকাউন্ট তৈরি হয়ে গেলে, systemd-কে নির্দেশ দিন যেন এটি ওই user হিসেবে service-টি চালায়। unit file-এ একটি লাইন দিয়ে এটি করা যায়:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

User=appsvc মানে হলো process-টি root-এর পরিবর্তে ওই account-এর সীমিত privileges নিয়ে শুরু হবে। systemd-এর অধীনে অ্যাপ্লিকেশন চালানোর এটি একটি সাধারণ এবং প্রচলিত পদ্ধতি, এবং আপনি যে কোনো service-এর জন্য unit লিখছেন তার ক্ষেত্রে এটি করা উচিত।

অথবা DynamicUser দিয়ে অ্যাকাউন্ট ছাড়াই চালানো

systemd আরও এক ধাপ এগিয়ে গিয়ে আপনার জন্য একটি throwaway user তৈরি করতে পারে, যা শুধুমাত্র service-টি চলাকালীন বিদ্যমান থাকে। DynamicUser=yes সেট করুন এবং আপনি কোনো অ্যাকাউন্ট পরিচালনা করবেন না:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

শুরুতে, systemd একটি অব্যবহৃত user ID বরাদ্দ করে; বন্ধ করার সময়, এটি তা রিলিজ করে দেয়। service-টি একটি প্রাইভেট /tmp পায়, যা filesystem-এর বেশিরভাগ অংশের একটি read-only ভিউ, এবং /var/lib/myapp এর অধীনে একটি writable state directory পায় যা StateDirectory= সেটআপ করে এবং প্রদান করে। একটি self-contained service যার শুধুমাত্র নিজস্ব state directory প্রয়োজন, তার জন্য DynamicUser=yes হলো শক্তিশালী isolation পাওয়ার সবচেয়ে সহজ উপায়, কারণ আক্রমণকারীর লক্ষ্য করার মতো কোনো দীর্ঘস্থায়ী অ্যাকাউন্ট সেখানে নেই।

হাতে লিখে unit তৈরি করা বেশ জটিল, এবং hardening directives গুলো সঠিকভাবে সেট করাটাই আসল কাজ। the systemd service and timer guide-এর generator আপনার জন্য এই অপশনগুলো পূরণ করে দিতে পারে যাতে প্রথমবারেই unit-টি সঠিক হয়।

এটি বাকিগুলোর সাথে কীভাবে সামঞ্জস্যপূর্ণ

Least privilege হলো একটি স্তর, এবং এটি অন্য স্তরগুলোর বিকল্প হিসেবে নয় বরং তাদের সাথে মিলে কাজ করে। একটি default-deny firewall নিয়ন্ত্রণ করে কী কী service-এ পৌঁছাতে পারে; একটি unprivileged user হিসেবে চালানো নিয়ন্ত্রণ করে service-টি breach হলে সেটি কী করতে পারে; এবং hardened SSH আক্রমণকারীদের শুরুতেই সার্ভার থেকে দূরে রাখে। এর কোনোটিই একা যথেষ্ট নয়, এবং একসাথে এগুলো নিশ্চিত করে যে একটি service-এর bug পুরো সার্ভারের compromise হয়ে উঠবে না।

এগোবার আগে, পুরো বক্সের জন্য একটি hardening checklist দেখে নিন এবং কাজ করার জন্য একটি পার্সোনালাইজড কপি তৈরি করুন:

FAQ

কেন আমার কোনো service root হিসেবে চালানো উচিত নয়?

কারণ root মেশিনে যেকোনো কিছু করতে পারে, তাই root হিসেবে চলা কোনো service যদি exploit হয়, তবে আক্রমণকারী পুরো সার্ভার পেয়ে যায়, শুধু service-টি নয়। service-টিকে একটি limited, unprivileged account হিসেবে চালানো সেই ক্ষতিকে কেবল ওই account-এর অ্যাক্সেসযোগ্য সীমার মধ্যে সীমাবদ্ধ রাখে। root-কে শুধুমাত্র administration-এর জন্য রাখুন, এবং প্রতিটি long-running service একটি restricted user হিসেবে চালান।

আমি কীভাবে এমন একটি user তৈরি করব যে লগ-ইন করতে পারবে না?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME চালান। nologin shell মানে হলো অ্যাকাউন্টটি চুরি হয়ে গেলেও আক্রমণকারী কোনো interactive session খুলতে পারবে না, --system এটিকে একটি service account হিসেবে চিহ্নিত করে, এবং --no-create-home অপ্রয়োজনীয় home directory এড়িয়ে চলে। chown দিয়ে এটিকে কেবল এর নিজস্ব ফাইলগুলোর মালিকানা দিন।

systemd DynamicUser কী?

DynamicUser=yes systemd-কে নির্দেশ দেয় service-এর জন্য একটি অস্থায়ী user তৈরি করতে যা শুধুমাত্র সেটি চলাকালীন বিদ্যমান থাকে, ফলে আপনাকে কোনো দীর্ঘস্থায়ী অ্যাকাউন্ট পরিচালনা করতে হয় না। এটি service-কে একটি প্রাইভেট /tmp, একটি মূলত read-only filesystem ভিউ এবং একটি managed state directory প্রদান করে। একটি self-contained service-কে একটি throwaway, low-privilege identity-র অধীনে চালানোর জন্য এটি সবচেয়ে সহজ উপায়।

non-root user হিসেবে চালানো কি firewall-এর বিকল্প?

না। তারা ভিন্ন ভিন্ন জিনিস রক্ষা করে। একটি unprivileged user হিসেবে চালানো নিয়ন্ত্রণ করে service-টি breach হলে সেটি কী করতে পারে, যেখানে একটি firewall নিয়ন্ত্রণ করে কী কী service-এ পৌঁছাতে পারে। উভয়ই ব্যবহার করুন, সেই সাথে hardened SSH ব্যবহার করুন, যাতে প্রতিটি স্তর একে অপরের অসম্পূর্ণতা পূরণ করতে পারে।

service user-এর মালিকানায় কোন ফাইলগুলো থাকা উচিত?

কেবল সেই ফাইলগুলো যা service-এর প্রকৃতপক্ষে প্রয়োজন, তার বেশি নয়। অ্যাকাউন্টটিকে তার নিজস্ব working directory এবং ডেটার মালিকানা দিন, এবং বাকি সবকিছু root-এর অধীনে থাকতে দিন। একটি ভালো প্যাটার্ন হলো অ্যাপ্লিকেশন ডিরেক্টরির জন্য sudo chown -R svc-app:svc-app /opt/svc-app ব্যবহার করা, যেখানে /etc এর অধীনে থাকা কনফিগারেশনগুলো root-এর মালিকানাধীন থাকবে এবং শুধুমাত্র service দ্বারা পড়া যাবে। লক্ষ্য হলো যে, যদি process-টি কখনো compromise হয়, তবে এটি কেবল এর নিজস্ব ডেটা পরিবর্তন করতে পারবে, সিস্টেমের বাকি অংশ নয়।