உங்கள் OpenVPN hook-ஐ எந்த systemd sandbox மறுத்தது என்பதைக் கண்டறிவது எப்படி

நீங்கள் அதை root ஆக கைமுறையாக இயக்கும்போது hook வேலை செய்கிறது, திரும்பத் தருகிறது Operation not permitted சேவை அதைத் தொடங்கும் தருணத்தில். அந்த இயக்கங்களுக்கிடையே கோப்பு மாறவில்லை; சூழல் மாறியது. systemd செயல்முறைக்கு சிறிய உலகத்தைத் தருகிறது: குறைவான திறன்கள், வேறுபட்ட /dev, படிக்க-மட்டும் கோப்பு முறைமை பாதைகள் மற்றும் ஒரு பணி உச்சவரம்பு. தோல்வியை ஒரு குறிப்பிட்ட செயல்பாட்டை மறுத்த எல்லையாகப் படியுங்கள், உடைந்த ஸ்கிரிப்டாக அல்ல.

மறுக்கப்பட்ட செயல்பாட்டிலிருந்து தொடங்குங்கள்

unit தோல்வியடைந்தது என்று சொல்லும் log வரி உங்களுக்கு கிட்டத்தட்ட எதையும் சொல்லாது. பயனுள்ள வரி மறுக்கப்பட்ட அழைப்பைப் பெயரிடுகிறது: திறக்க முடியாத சாதன முனை, எழுத முடியாத அடைவு, உருவாக்க முடியாத namespace. ஒரு கட்டளைக் கூடத் தொடுவதற்கு முன் அந்த அழைப்பைக் கண்டறியுங்கள், ஏனெனில் ஒவ்வொன்றும் வேறு கட்டுப்பாட்டுடன் பொருந்துகிறது. பின்னர் தொகுப்பு வழங்கிய கோப்புக்கு பதிலாக உண்மையில் இயங்கிய unit-ஐப் படியுங்கள், drop-in-கள் உட்பட.

கீழேயுள்ள வினவல் fragment பாதை, drop-in அடைவுகள் மற்றும் சாதனம் அல்லது கோப்பு முறைமை மறுப்புக்கு முக்கியமான பண்புகளை அச்சிடுகிறது. எந்த எல்லை பொருத்தமானது என்று முடிவெடுக்கும் முன் அவை அனைத்தையும் படியுங்கள்:

systemctl show "[email protected]" -p FragmentPath -p DropInPaths -p PrivateDevices -p DevicePolicy -p DeviceAllow -p ProtectHome -p ProtectSystem -p TasksMax
journalctl -u "[email protected]" -b --no-pager | grep -iE 'operation not permitted|permission denied|cannot open|failed'

அந்தத் தொகுதியில் எதுவும் எழுதவில்லை. மறுக்கப்பட்ட அழைப்பு journal-இல் இல்லை என்றால், கட்டளைகளை ஊகிப்பதற்கு பதிலாக ஒரு இயக்கத்திற்கு client-இன் விவர அளவை உயர்த்துங்கள். இயங்கும் செயல்முறை unit தொடங்கியதை நிரூபிக்கிறது, hook தேவையான சிறப்புரிமைகளுடன் இயங்கியதை அல்ல.

ஒரு TUN சாதனம் ஒருபோதும் பயன்படுத்தாத mount உரிமைகள் namespace-க்குத் தேவை

ஒரு hook-க்குள் ஒரே மாதிரி தோன்றும் இரண்டு செயல்பாடுகளுக்கு வெவ்வேறு அனுமதி விவரக்குறிப்புகள் உள்ளன. திறப்பது /dev/net/tun மற்றும் இடைமுகத்தை உருவாக்குவது network administration மற்றும் அந்த முனைக்கான அணுகல் தேவை. பெயரிடப்பட்ட network namespace உருவாக்குவதற்கும் mount தொடர்பான வேலை தேவை, ஏனெனில் namespace கருவி புதிய /sys பார்வையை mount செய்து ஒரு நிலை அடைவை அதன் இடத்தில் பிணைக்கிறது. மேல்நிலை client unit வேண்டுமென்றே mount administration-ஐ அதன் bounding set-க்கு வெளியே விட்டுவிடுகிறது, எனவே namespace படி மறுக்கப்படுகிறது, tunnel தானே வேலை செய்திருக்கும்.

அதனால்தான் சாதன முனையை வழங்குவது ஸ்கிரிப்டைக் காப்பாற்றாது. சாதன அனுமதி ஒரு கேள்விக்கு பதிலளிக்கிறது, இந்தச் செயல்முறை இந்த முனையைத் திறக்கலாமா, namespace கேள்வி வேறு ஒன்று. எதையும் விரிவுபடுத்தும் முன் தோல்வியடையும் அழைப்பை அதன் திறனுடன் பொருத்துங்கள்.

உங்கள் shell-இல் உள்ள சோதனை கட்டுப்பாடற்ற root வைத்திருக்கும் ஒவ்வொரு திறனையும் பெறுகிறது, unit அதன் bounding set தக்கவைத்ததைப் பெறுகிறது. அந்த இரண்டு இயக்கங்களும் வெவ்வேறு சோதனைகள் binary ஒன்றாக இருந்தாலும்.

சாதனங்கள், பாதுகாக்கப்பட்ட பாதைகள் மற்றும் பணி உச்சவரம்புகள்

மறுக்கப்பட்ட செயல்பாடு தெரிந்ததும், மூன்று குழு கட்டளைகள் பெரும்பாலான தோல்விகளை விளக்குகின்றன. சாதன அணுகலை PrivateDevices கட்டுப்படுத்துகிறது, இது /dev -ஐ குறைந்தபட்ச போலி-சாதனங்களின் தொகுப்பால் மாற்றுகிறது, மேலும் DevicePolicy உடன் DeviceAllow சேர்ந்து cgroup அனுமதிப்பதைத் தீர்மானிக்கின்றன. /dev/net/tun அந்தக் குறைந்தபட்ச தொகுப்பின் பகுதி அல்ல, எனவே PrivateDevices=yes உள்ள unit அதைத் திறக்க முடியாது, சாதனக் கொள்கை என்ன சொன்னாலும்.

கோப்பு முறைமை பாதுகாப்பு இரண்டாவது கேள்விக்கு பதிலளிக்கிறது. ProtectHome=yes -ஆல் /home, /root மற்றும் /run/user ஆகியவை அணுக முடியாததாக ஆக்கப்படுகின்றன, மேலும் ProtectSystem=full -ஆல் /usr, /boot மற்றும் /etc ஆகியவை படிக்க-மட்டும் ஆக்கப்படுகின்றன. எனவே தன் சொந்த configuration கோப்பின் அருகில் எழுதும் hook உங்கள் shell-இல் வேலை செய்து unit-இன் கீழ் தோல்வியடைகிறது, காணாமல் போன திறனைப் போன்ற அதே அனுமதி வடிவத்துடன். எழுதக்கூடிய உள்ளீட்டைக் கொள்கை அனுமதிக்கும் பாதைக்கு நகர்த்துங்கள், அல்லது ஒரு குறுகிய ReadWritePaths= உள்ளீட்டைச் சேர்க்கவும்.

வள வரம்புகள் மூன்றாவது குழு, மிகக் குறைவாகத் தெரிபவை. TasksMax= unit உருவாக்கக்கூடிய பணிகளின் எண்ணிக்கையை வரம்பிடுகிறது, மேலும் கோப்பு-விவரிப்பான் உச்சவரம்பு socket மற்றும் handle-களுக்கு அதே வழியில் செயல்படுகிறது. உச்சவரம்பைத் தாண்டி வளர்ந்த deployment அனுமதி பிழைக்கு பதிலாக வள பிழையுடன் தோல்வியடைகிறது, அதனால்தான் சரியான செய்தி இன்னும் முக்கியம்.

namespace படியை hook-இலிருந்து வெளியே நகர்த்துங்கள்

client வைத்திருக்கக்கூடாத சிறப்புரிமை தேவைப்படும் தயாரிப்பு அதன் சொந்த unit-இல் இருக்க வேண்டும். client-க்கு முன் இயங்கி, அதன் முடிவைத் தக்கவைத்து, இணைப்புக்கு முன் வரிசைப்படுத்தப்பட்ட ஒரு oneshot namespace படிக்குத் தேவையானதைத் தருகிறது, அந்த உரிமைகளை tunnel செயல்முறைக்கு வழங்காமல். பின்னர் client அந்த unit-ஐ குறிப்பிடுகிறது, தன் up hook-இலிருந்து ஸ்கிரிப்டை அழைப்பதற்கு பதிலாக.

கீழேயுள்ள template ஒரு தொடக்க வடிவம், படிக்காமல் பயன்படுத்த வேண்டிய ஒன்று அல்ல. சிறப்புரிமை வாழும் இடத்தில் தயாரிப்பை வைத்து tunnel unit-ஐ தொடாமல் விடுகிறது:

# /etc/systemd/system/[email protected]
[Unit]
Description=Namespace preparation for %i
Before=openvpn-client@%i.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/netns-up.sh %i
CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN
[Install]
WantedBy=multi-user.target

தொகுக்கப்பட்ட unit-ஐ திருத்துவதற்கு பதிலாக drop-in மூலம் வரிசையைச் சேர்க்கவும், எனவே ஒரு மேம்படுத்தல் உங்கள் மாற்றத்தை அமைதியாக விட்டுவிட முடியாது. அடைவு instance பெயருடன் இணைக்கப்பட்டுள்ளது, எனவே இரண்டாவது profile-க்கு அதன் சொந்த கோப்பு தேவை:

sudo mkdir -p /etc/systemd/system/[email protected]
sudo tee /etc/systemd/system/[email protected]/10-namespace.conf >/dev/null <<'CONF'
[Unit]
[email protected]
[email protected]
CONF
sudo systemctl daemon-reload

மாற்றத்திற்குப் பிறகு அதே அழைப்பை மீண்டும் செய்யுங்கள்

அதே அழைப்பு வேறு முடிவைத் தந்தால் மட்டுமே பழுது உறுதிப்படுத்தப்படுகிறது. இரண்டு unit-களையும் மறுதொடக்கம் செய்யுங்கள், தோல்வியடைந்த செயல்பாட்டை இயக்குங்கள், அதன் விளைவை மாற்றத்திற்கு முன் சேமித்த journal வரியுடன் ஒப்பிடுங்கள். hook மீண்டும் ஒருபோதும் இயங்காத நிலையில் தொடங்கும் unit பழுது அல்ல.

கீழேயுள்ள வரிசை ஒப்பீட்டை நேர்மையாக வைத்திருக்கிறது, ஏனெனில் இது unit-இன் நிறத்தை அல்ல, மறுக்கப்பட்ட அழைப்பைச் சரிபார்க்கிறது. அதன் வெளியீட்டை மாற்றத்திற்கு முன் பிடித்த journal வரிக்கு அருகில் சேமியுங்கள்:

sudo systemctl restart "[email protected]" "[email protected]"
systemctl status "[email protected]" --no-pager
journalctl -u "[email protected]" -b --no-pager | grep -c 'Operation not permitted'
ip -brief addr show tun0

கடைசி வரியைப் படிப்பதற்கு பதிலாக மறுப்புகளை எண்ணுங்கள், ஏனெனில் ஒரு hook தோல்வியடைந்து, மீண்டும் முயன்று வெற்றிபெறலாம், எல்லை நகர்ந்ததா என்பதை எண்ணிக்கை மட்டுமே காட்டுகிறது. drop-in-இல் நீங்கள் தளர்த்திய கட்டளையையும் காரணத்தையும் பெயரிடும் கருத்தை விடுங்கள், ஏனெனில் அடுத்த மேம்படுத்தல் உங்கள் configuration-ஐ தொகுக்கப்பட்ட இயல்புநிலையுடன் ஒப்பிடுகிறது. ஒவ்வொரு பாதுகாப்பும் முடக்கப்பட்ட பிறகு மட்டுமே தொடங்கும் unit சரிசெய்யப்படவில்லை.