root இல்லாமல் OpenVPN-க்கு 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 எல்லையை நகர்த்தியதா என்பதைக் காணலாம்.

தொடர்புடைய கட்டுரைகள்