OpenVPN இல் chroot தோல்வியடைகிறது: AppArmor விதியா அல்லது திறனா?

டீமன் chroot தோல்வியைப் பதிவு செய்கிறது, சுயவிவரம் ஏற்கனவே தாராளமாகத் தெரிகிறது, எனவே கவர்ச்சிகரமான திருத்தம் பாதை விதியை விரிவாக்கி மீண்டும் தொடங்குவதாகும். அது பொதுவாக எதையும் மாற்றாது, ஏனெனில் chroot என்பது சுயவிவரம் ஒருபோதும் வழங்க முடியாத ஒரு சிறப்புரிமையால் கட்டுப்படுத்தப்படுகிறது. எந்த அடுக்கைத் தொடுவது என்பதை முடிவு செய்ய மூன்று சோதனைகள் தேவை, அவை மலிவானவை: செயல்முறை எதை வைத்திருக்க அனுமதிக்கப்படுகிறது, கொள்கை எதை அனுமதிக்கிறது, மற்றும் அவை இரண்டும் முக்கியமாகும் முன் தொடக்கி எதை நீக்கியது.

இரண்டு தனித்த வாயில்கள், அவற்றில் ஒன்று மட்டுமே AppArmor உடையது

chroot க்கு செயல்முறை இயங்கும் பயனர் பெயர்வெளியில் CAP_SYS_CHROOT தேவை. இது வழக்கமான Linux சிறப்புரிமை, அழைப்பு பாதைகளுடன் எதையும் செய்வதற்கு முன் கர்னல் இதைச் சரிபார்க்கிறது. தனியாக, செயல்படுத்தும் AppArmor சுயவிவரம் செயல்முறை அதை வைத்திருந்தாலும் அந்தத் திறனை மறுக்கலாம், ஏனெனில் கட்டாயக் கொள்கை அடையாளச் சான்றுகளுக்குப் பதிலாக அல்லாமல் அவற்றுடன் சேர்த்துப் பரிசீலிக்கப்படுகிறது. இந்த வேறுபாடு நடைமுறையில் முக்கியம்: இரண்டு அடுக்குகளும் வெவ்வேறு கோப்புகளில் வாழ்கின்றன, பொதுவாக வெவ்வேறு நபர்களால் பராமரிக்கப்படுகின்றன.

அந்த இரண்டு வாயில்களும் ஒரே errno உடன் தோல்வியடைகின்றன. இரண்டும் EPERM ஐ உருவாக்குகின்றன, இரண்டும் டீமன் பதிவில் பொதுவான அனுமதி புகாராகத் தோன்றுகின்றன, அதனால்தான் சுயவிவரத்தின் உள்ளடக்கத்தை ஊகிப்பது இவ்வளவு நேரத்தை வீணாக்குகிறது. நீங்கள் சேர்க்க இருந்த பாதை விதி chroot வெற்றிபெற்ற பிறகு கோப்பு அணுகலைக் கட்டுப்படுத்துகிறது; செயல்பாடு அனுமதிக்கப்படுகிறதா என்பதில் அதற்கு எந்தத் தொடர்பும் இல்லை.

மூன்றாவது வாயில் இரண்டிற்கும் மேலே உள்ளது. சேவை மேலாளர் அல்லது ஒரு மேலோட்டம் செயல்முறையை அதன் எல்லைத் தொகுப்பில் அந்தத் திறன் இல்லாமல் தொடங்கியிருந்தால், எந்த AppArmor மாற்றமும் அதைத் திரும்பக் கொண்டுவர முடியாது, சுயவிவரத்தில் திறன்களைச் சேர்ப்பது கர்னல் நிறைவேற்றாத ஒரு நோக்கத்தைப் பதிவு செய்வதே ஆகும்.

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

நீங்கள் செயலில் இருப்பதாக நம்பும் கட்டமைப்பிலிருந்து அல்ல, இயங்கும் செயல்முறையிலிருந்து தொடங்குங்கள். நிலைக் கோப்பு ஐந்து திறன் முகமூடிகளையும் no-new-privileges கொடியையும் காட்டுகிறது, அவை வெவ்வேறு கேள்விகளுக்குப் பதிலளிக்கின்றன:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff என்பது அழைப்பிற்கு முக்கியமான தொகுப்பு: CapBnd இல் இருந்து CapEff இல் இல்லாத திறன் உச்சவரம்பால் அனுமதிக்கப்பட்டு அந்த நேரத்தில் வைத்திருக்கப்படவில்லை. பைனரி வழக்கமான setuid பொருளில் சிறப்புரிமை பெறாதபோது CapAmb முக்கியம், ஏனெனில் சூழல் திறன்கள் என்பது கோப்பு திறன்கள் இல்லாமல் exec வழியாக ஒரு சேவை சிறப்புரிமையைத் தக்கவைக்கும் வழியாகும். CapInh exec வழியாக மரபுரிமையாகக் கிடைக்கக்கூடிய பிட்டுகளை வைத்திருக்கிறது, ஆனால் இயக்கப்படும் கோப்பின் மரபுரிமைத் தொகுப்பு அனுமதிக்கும்போது மட்டுமே, எனவே அங்குள்ள ஒரு பிட் தனியாக எதையும் வழங்காது.

பின்னர் எந்த சுயவிவரம் உண்மையில் இணைக்கப்பட்டுள்ளது என்பதை உறுதிப்படுத்துங்கள். ஒரு செயல்முறை நீங்கள் எதிர்பார்க்காத சுயவிவரப் பெயரால் கட்டுப்படுத்தப்பட்டிருக்கலாம், குறிப்பாக ஒரு விநியோகம் தனது unit ஐயும் சுயவிவரத்தையும் ஒன்றாக வழங்கும்போது, /proc/PID/attr/current ஐப் படிப்பது அதை ஒரே வரியில் தீர்க்கிறது. கர்னல் அறிவிக்கும் சுயவிவரத்துடன் நீங்கள் திருத்திய கோப்பை ஒப்பிடுவது காரணத்தைச் சரிசெய்வதற்கும் யாரும் ஏற்றாத கோப்பைத் திருத்துவதற்கும் இடையிலான வேறுபாடு.

தணிக்கைத் தடம் அவ்வாறு கூறும்போது மட்டுமே திறன் விதியைச் சேருங்கள்

கர்னல் மற்றும் தணிக்கைப் பதிவுகள் மறுத்த அடுக்கைப் பெயரிடுகின்றன. capable செயல்பாடு மற்றும் sys_chroot என்ற பெயருடன் கூடிய மறுப்பையும், அதை உருவாக்கிய சுயவிவரத்தையும் தேடுங்கள். அந்தப் பதிவு இருந்தால், செயல்முறை ஏற்கனவே அந்தத் திறனை வைத்திருந்தது, AppArmor அதை மறுத்தது, இலக்கு மாற்றம் உண்மையான சுயவிவரத்திற்குள் ஒரு திறன் விதியாகும்:

capability sys_chroot,

அதை உண்மையில் இணைக்கப்பட்ட சுயவிவரத்தில் ஒரு துண்டாக வைத்திருங்கள், தொடர்பற்ற பயிற்சியிலிருந்து விதியை நகலெடுப்பதற்குப் பதிலாக முக்கியச் சொல்லை apparmor.d சுயவிவரக் குறிப்பு உடன் சரிபார்க்கவும். பகிரப்பட்ட include இல் வைப்பது அந்தக் கோப்பை ஏற்றும் ஒவ்வொரு கட்டுப்படுத்தப்பட்ட நிரலுக்கும் அதை வழங்கும், சுயவிவரத்தை complain பயன்முறைக்கு மாற்றுவது இதைத் தீர்ப்பதற்குப் பதிலாக அடுத்த மறுப்பை மறைக்கும். சுயவிவர விதி கொள்கை மறுப்பை நீக்குகிறது; அது சிறப்புரிமையை உருவாக்காது, எனவே தன் செயல்திறன் தொகுப்பில் CAP_SYS_CHROOT ஒருபோதும் இல்லாத செயல்முறை விதி இருந்தாலும் தோல்வியடையும்.

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

சேவை மேலாளர் தனது சொந்த உச்சவரம்பை வைத்திருக்கிறார்

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

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

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

மறுப்பு நீங்கிய பிறகு, சிறையையே சரிபார்க்கவும்

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

chroot எதைச் செய்யாது என்பதை நினைவில் கொள்வதும் உதவும். இது ஒரு பாதை எல்லை, sandbox அல்ல: சிறப்புரிமையைத் தக்கவைக்கும் செயல்முறை அதிலிருந்து தப்பிக்கலாம், அதனால்தான் திறன் பொதுவாக அழைப்பிற்குப் பிறகு விடப்படுகிறது, கட்டுப்பாடு டீமனைச் சுற்றி இருக்க வேண்டும். AppArmor சுயவிவரம், திறன் எல்லைத் தொகுப்பு மற்றும் கோப்பு முறைமைக் கட்டுப்பாடுகளை ஒன்றாக வைத்திருப்பதே இந்தப் பயிற்சியின் நோக்கம், சேவை தொடங்கிய பிறகு அகற்ற வேண்டிய மீதி அல்ல.

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