OpenVPN کو root دیے بغیر CAP_NET_ADMIN دینا

سروس شروع ہوتی ہے، لاگ شکایت کرتا ہے کہ وہ tun ڈیوائس نہیں کھول سکتا، اور راستے کبھی ظاہر نہیں ہوتے۔ اپنے شیل میں capsh --print چلائیں اور cap_net_admin وہیں موجود ہے، جو ناکامی کو ناممکن دکھاتا ہے۔ آپ کے شیل اور یونٹ میں فرق مراعات کی منتقلی ہے، نہ کہ کرنل کی صلاحیت دینے کی آمادگی۔ نیچے دیے گئے چار جائزے ترتیب سے کریں اور پہلے جائزے پر رکیں جو فرق کی وضاحت کرے۔

غائب صلاحیت کو چھپی ہوئی ڈیوائس سے الگ کریں

لاگ لائن سے دو ناکامیاں ایک جیسی نظر آتی ہیں۔ CAP_NET_ADMIN کے بغیر عمل ٹنل کا انٹرفیس نہ بنا سکتا ہے نہ ترتیب دے سکتا ہے، اور جس عمل کا سینڈ باکس /dev/net/tun چھپاتا ہے وہ اسے شروع ہی سے نہیں کھول سکتا۔ صلاحیتیں شامل کرنے سے دوسری صورت درست نہیں ہوگی۔

کچھ بھی ترمیم کرنے سے پہلے دیکھیں کہ ڈیوائس سروس کے نام کی جگہ کے اندر موجود ہے یا نہیں۔ PrivateDevices=yes ایک عام سختی کی لائن ہے جو tun نوڈ کو مکمل طور پر ہٹا دیتی ہے، اور پابند ProtectSystem ترتیب کے راستے کو اس طرح صرف پڑھنے کے قابل بنا سکتا ہے جو اجازت کی غلطی کی طرح پڑھا جائے۔ دونوں ٹنل کا ذکر کرنے والی لاگ لائنیں بناتے ہیں، اسی لیے الزام صلاحیتوں پر لگتا ہے۔ پہلے تصدیق کریں کہ نوڈ موجود ہے اور کھل سکتا ہے، پھر آگے بڑھیں۔

جانیں کہ آپ کون سا صلاحیت مجموعہ دیکھ رہے ہیں

Linux اجازت یافتہ، مؤثر، وراثت پذیر، محدود اور ماحولی مجموعے رکھتا ہے، اور ماحولی مجموعہ ہی وہ ہے جو غیر root صارف کے exec کے بعد بچتا ہے۔ بائنری پر فائل صلاحیتیں exec کے وقت اجازت یافتہ اور مؤثر حقوق منتقل کر سکتی ہیں، لیکن صرف اس وقت تک جب تک زنجیر میں کوئی چیز اس منتقلی کو نہ روکے۔

یہیں sudo لوگوں کو گمراہ کرتا ہے۔ sudo -u کے ذریعے چلایا گیا حکم مراعات کی نئی منتقلی شروع کرتا ہے اور ماحولی مجموعہ ختم ہو جاتا ہے، اس لیے وہی جائزہ جو root کے طور پر کامیاب ہوتا ہے وہاں ناکام ہوتا ہے۔ سروس مینیجر ایک اور منتقلی ہے، اور یونٹ کے کہنے کے بغیر وہ ماحول میں کچھ نہیں دیتا۔

صلاحیت یونٹ میں دیں، ریپر میں نہیں

ایسی ٹنل کے لیے کم سے کم سروس سیکشن جسے ڈیوائس بنانا اور راستے نصب کرنے ہوں، ایسا دکھتا ہے۔

[Unit]
Description=OpenVPN client, office profile
After=network-online.target

[Service]
Type=notify
User=openvpn
Group=openvpn
NoNewPrivileges=yes
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/office.conf

AmbientCapabilities عمل شروع ہونے سے پہلے حق کو ماحولی مجموعے میں رکھتا ہے، اور CapabilityBoundingSet عمل کو اس فہرست سے باہر کچھ رکھنے سے روکتا ہے۔ NoNewPrivileges=yes setuid یا فائل صلاحیتوں کے ذریعے مراعات حاصل کرنے کو روکتا ہے، جبکہ یونٹ کی واضح طور پر دی گئی صلاحیت پھر بھی لاگو رہتی ہے۔ CAP_NET_BIND_SERVICE صرف اس وقت شامل کریں جب سروس کو کم پورٹ باندھنا ہو، اور کبھی CAP_SYS_ADMIN صرف اس لیے شامل نہ کریں کہ کسی فورم تھریڈ نے ایسا کیا۔

اگر یونٹ بائنری کو sudo میں لپیٹتا ہے تو ریپر ہٹا دیں۔ systemd پہلے ہی User= لاگو کرتا ہے، اور وہی اضافی پرت ماحولی مجموعہ خالی ہونے کی سب سے زیادہ ممکنہ وجہ ہے۔

یونٹ فائل پر نہیں، زندہ عمل پر تصدیق کریں

پڑھیں کہ مینیجر نے واقعی کیا لاگو کیا، پھر وہ عمل پڑھیں جو اس نے پیدا کیا۔

unit=openvpn-client@office
systemctl show -p User -p AmbientCapabilities "$unit"
systemctl show -p MainPID --value "$unit" | xargs -r getpcaps
grep -E '^Cap(Eff|Amb)' /proc/$(systemctl show -p MainPID --value "$unit")/status

اگر یونٹ صلاحیت درج کرتا ہے اور CapEff میں اب بھی وہ نہیں ہے، تو کوئی drop-in ترتیب کو نظر انداز کر رہا ہے یا ExecStartPre مرحلہ ماحول بدل رہا ہے۔ اہم فائل کو مستند ماننے سے پہلے drop-in ڈائریکٹریوں میں یونٹ کا نام تلاش کریں، کیونکہ بعد کی فائل خاموشی سے جیت جاتی ہے۔ اگر یونٹ اور عمل دونوں صلاحیت دکھاتے ہیں اور ٹنل پھر بھی ناکام ہوتی ہے تو محدود مجموعہ بڑھانے کے بجائے ڈیوائس اور راستے کے جائزوں کی طرف واپس جائیں۔ اسے بڑھانا اصل وجہ چھپا دیتا ہے اور سروس کو پہلے سے زیادہ مراعات یافتہ چھوڑ دیتا ہے۔

شروع ہونے کے بعد مراعات چھوڑ دینا ترجیح دیں

OpenVPN اپنے user اور group اختیارات کے ذریعے مراعات کے ساتھ شروع ہو کر بعد میں غیر مراعات یافتہ اکاؤنٹ میں اتر سکتا ہے، اور persist-key اور persist-tun ٹنل کو بعد میں بھی قابل استعمال رکھتے ہیں۔ یہ ترتیب اس دورانیے کو تنگ کرتی ہے جس میں عمل کے پاس حقوق ہوتے ہیں، اور مستقل صلاحیتوں کے ساتھ پورے ڈیمن کو غیر مراعات یافتہ شروع کرنے سے یہ اکثر زیادہ موزوں ہوتی ہے۔

آپ کوئی بھی ماڈل منتخب کریں، یونٹ دوبارہ شروع کریں اور ری بوٹ کے بعد جائزے دہرائیں، کیونکہ انٹرایکٹو root شیل سے کام کرنے والی مگر بوٹ پر ناکام ہونے والی سروس عام طور پر صلاحیت، ڈیوائس یا فائل اجازت کا فرق ہوتی ہے۔ یونٹ کی ترتیبات عمل کی صلاحیت کے آؤٹ پٹ کے ساتھ لکھیں، تاکہ اگلا جائزہ لینے والا دیکھ سکے کہ پیکیج اپ ڈیٹ یا drop-in نے حد کو ہلایا ہے یا نہیں۔