OpenVPN ને root આપ્યા વિના CAP_NET_ADMIN આપવું

બિન-વિશેષાધિકૃત વપરાશકર્તા તરીકે શરૂ થતા યુનિટને હજી પણ યોગ્ય ક્ષમતા-સમૂહની જરૂર છે. યુનિટ, જીવંત પ્રક્રિયા અને exec સીમા આ ક્રમમાં તપાસો.

સેવા શરૂ થાય છે, લોગ ફરિયાદ કરે છે કે તે 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 એ સીમા ખસેડી છે કે નહીં.

સંબંધિત લેખો