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 ले सीमा सारेको छ कि छैन देख्न सकून्।