Linux-এ অনুমতি «এই ফাইলটা কে পড়তে পারে» প্রশ্নের উত্তর দেয়। AppArmor উত্তর দেয় অন্যটির: «এই প্রোগ্রাম আদৌ কী করতে পারে»। পার্থক্যটা দেখা যায় সিঁধ কাটার সময়। web shell ওয়েব সার্ভারের ব্যবহারকারী হিসেবে চলে আর তার সব অধিকার পায় — অর্থাৎ সিস্টেমের অর্ধেকেরও বেশিতে পড়ার প্রবেশাধিকার। AppArmor প্রোফাইল প্রক্রিয়াটিকে তার কাজের জন্য যা দরকার সেই তালিকাতেই সীমিত করে, আর /etc/shadow পড়ার বা /bin/bash চালানোর চেষ্টা ব্যবহারকারীর অনুমতি নির্বিশেষে প্রত্যাখ্যানে শেষ হয়।
আগে থেকেই কী চালু
sudo aa-statusফলাফল তিনটি প্রশ্নের উত্তর দেয়: কতগুলো প্রোফাইল লোড হয়েছে, তাদের কতগুলো enforce ও complain মোডে, আর কোন প্রক্রিয়া কোনো প্রোফাইল ছাড়াই চলে। সাধারণ Ubuntu-তে কয়েক ডজন প্রোফাইল থাকবে, কিন্তু প্রায় সবই man ও tcpdump-এর মতো সহায়ক প্রোগ্রামের। মূল সেবাগুলো — nginx, Apache, PHP-FPM — সাধারণত সীমিতদের তালিকায় থাকে না।
তিনটি মোড আলাদা করা দরকার:
- enforce — নিয়ম প্রয়োগ হয়, বাড়তি সবকিছু প্রত্যাখ্যাত;
- complain — লঙ্ঘন কেবল জার্নালে নথিভুক্ত হয়, কিছুই আটকানো হয় না। সমন্বয়ের মোড;
- unconfined — প্রোফাইল নেই, প্রোগ্রাম বিধিনিষেধ ছাড়াই চলে।
aa-status-এর ফলাফলের সবচেয়ে কাজের অংশ শেষেরটি: যেসব প্রক্রিয়া নেটওয়ার্কে শোনে আর কিছু দিয়েই সীমিত নয়। শুরু করা উচিত ওই তালিকা দিয়েই।
সরঞ্জাম
sudo apt install apparmor-utilsওই প্যাকেজ ছাড়া aa-complain, aa-enforce ও aa-logprof কমান্ড সিস্টেমে থাকে না, যদিও খোদ AppArmor চলছে।
সেবা না থামিয়ে প্রোফাইল কীভাবে চালু করবেন
ক্রমটা মৌলিক। সরাসরি enforce-এ দেওয়া প্রোফাইল উচ্চ সম্ভাবনায় সেবাকে দরকারি কিছু থেকে বঞ্চিত করবে, আর সেটি কাজ করা বন্ধ করবে — সাধারণত সঙ্গে সঙ্গে নয়, বরং কোনো বিরল কাজে, যেমন ফাইল আপলোড বা মেইল পাঠানো।
সঠিক ক্রম:
sudo aa-complain /etc/apparmor.d/usr.sbin.nginxওই মোডে এক সপ্তাহের কাজ, প্রতিটি অস্বাভাবিক পরিস্থিতিসহ: ব্যাকআপ নেওয়া, হালনাগাদ, বড় ফাইল আপলোড। তারপর যা জমেছে তার মধ্য দিয়ে যান:
sudo aa-logprofকমান্ডটি নথিভুক্ত লঙ্ঘনের মধ্য দিয়ে যায় আর প্রতিটির বিষয়ে জিজ্ঞেস করে অনুমতি দেবেন কি না। এখানে মনোযোগ দরকার: সত্যিই সেবার কাজের অংশ যা তাতেই অনুমতি দিন, চোখে পড়া সবকিছুতে নয় — নইলে এমন প্রোফাইল দাঁড়ায় যা সবকিছুর অনুমতি দেয়, আর অর্থটা হারিয়ে যায়।
আর কেবল তারপরে:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginxপ্রত্যাখ্যান কোথায় দেখবেন
সব লঙ্ঘন কার্নেলের জার্নালে যায়:
sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.logদ্বিতীয় ফাইলটি থাকে যদি auditd বসানো থাকে — আর তার সঙ্গে এন্ট্রি লক্ষণীয়ভাবে বেশি বিশদ। প্রত্যাখ্যানের এন্ট্রি দেখায় প্রোফাইলের নাম, চাওয়া কাজ আর যে পথে প্রবেশ চাওয়া হয়েছিল; প্রোফাইল ঠিক করতে হবে নাকি সেটি চলেছে বলে খুশি হতে হবে তা বোঝার জন্য এটুকুই যথেষ্ট।
একটা লক্ষণ মনে রাখার মতো: সেবা অদ্ভুত আচরণ করে — কনফিগ পড়ে না, ডিরেক্টরিতে লেখে না, সকেট খোলে না — অথচ তার নিজের লগে «permission denied» ত্রুটি আর অনুমতি স্পষ্টতই সঠিক। এটা প্রায় সবসময় AppArmor, আর প্রথম কাজ কার্নেলের জার্নালে দেখা।
ব্যবহারিক ব্যবস্থা, তাত্ত্বিক নয়
PHP-FPM বা nginx-এর প্রোফাইল একটা নির্দিষ্ট উপায়ে নিজের দাম উশুল করে। প্রক্রিয়া সীমিত থাকলে সাইটে পৌঁছানো web shell না সিস্টেম ফাইল পড়তে পারে, না শেল চালাতে পারে, না অনুমোদিত ডিরেক্টরির বাইরে কিছু লিখতে পারে। হ্যাক হওয়া সাইট হ্যাক হওয়া সাইটই থাকে, গোটা যন্ত্রে প্রবেশাধিকারে পরিণত হয় না — আর ক্ষতির বড় অংশ ওই রূপান্তরেই।
গ্রহণের যুক্তিসঙ্গত ক্রম: আগে যা ইন্টারনেটের দিকে তার প্রোফাইল (ওয়েব সার্ভার, PHP-FPM), তারপর ডেটাবেসের, তারপর প্রয়োজনমতো। সব একসঙ্গে চালু করার দরকার নেই, আর সর্বজনীন তৈরি সেটও নেই: প্রোফাইল নির্ভর করে আপনার ফাইল কোথায় থাকে তার উপর।
নিয়মিত কী যাচাই করবেন
প্রোফাইল আপনার ধারণার চেয়ে বেশিবার unconfined-এ ফিরে যায়: প্যাকেজ হালনাগাদ প্রোফাইল ফাইল বদলে দিতে পারে, হাতে করা ডিবাগ সেবাকে complain-এ রেখে যায়, আর নতুন সেবা প্রোফাইল ছাড়াই আসে। দুটি সংখ্যা কাজের: কতগুলো প্রোফাইল enforce-এ, আর নেটওয়ার্কের দিকে মুখ করা কতগুলো প্রক্রিয়া unconfined। দুটির যেকোনোটির পরিবর্তন জানার মতো। এক পাতায় জোড়া লাগানো অবস্থায় এটি কেমন দেখায় তা নিচের ডেমোতে।