Linux சேவைகளை root இல்லாமல் இயக்குவது எப்படி

ஏன் அனைத்தையும் root ஆக இயக்கக்கூடாது

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

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

ஒரு சேவைக்கு ஒரு பிரத்யேக கணக்கு

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

sudo useradd --system --no-create-home --shell /usr/sbin/nologin appsvc

ஒவ்வொரு flag முக்கியமானது. --system அதை மனித உள்நுழைவு அல்லாமல் சேவை கணக்காக மாற்றுகிறது. --no-create-home தேவையில்லாத home directory ஐ தவிர்க்கிறது. --shell /usr/sbin/nologin என்பது ஒரு தாக்குபவர் எப்படியாவது கணக்கைப் பெற்றாலும், அவர்களால் அதில் shell ஐ திறக்க முடியாது என்பதாகும். இந்த கணக்கு ஒரு process ஐயும் அதன் கோப்புகளையும் வைத்திருக்க மட்டுமே உள்ளது.

பின்னர் அந்த பயனருக்கு அதற்கு தேவையான கோப்புகளை மட்டும் கொடுங்கள், அதற்கு மேல் ஒன்றுமில்லை:

sudo chown -R appsvc:appsvc /opt/myapp

இப்போது சேவை அதன் சொந்த directory ஐ படித்து எழுதுகிறது, மேலும் வட்டின் வேறு எங்கும் அதற்கு வேலை இல்லை. அது எப்போதாவது சுரண்டப்பட்டால், தாக்குபவர் மாற்றக்கூடிய கோப்புகள் /opt/myapp க்கு மட்டுப்படுத்தப்படுகின்றன; கணக்கு உலகளாவிய படிக்கக்கூடிய எதையும் படிக்க முடியும், ஆனால் கணினியின் மீதமுள்ளவற்றை அது மாற்ற முடியாது.

systemd அதை அந்த பயனராக இயக்கட்டும்

கணக்கு உருவாக்கப்பட்டதும், systemd க்கு சேவையை அதாக இயக்கச் சொல்லுங்கள். unit கோப்பில், ஒரு வரி அதைச் செய்கிறது:

[Service]
ExecStart=/opt/myapp/bin/server
User=appsvc
Group=appsvc

User=appsvc என்பது process ஆனது root இன் அதிகாரங்களுக்கு பதிலாக அந்த கணக்கின் வரம்பிற்குட்பட்ட அதிகாரங்களுடன் தொடங்குகிறது என்பதாகும். இது systemd கீழ் ஒரு பயன்பாட்டை இயக்குவதற்கான சாதாரண, நன்கு அறியப்பட்ட வழியாகும், மேலும் நீங்கள் ஒரு unit எழுதும் ஒவ்வொரு சேவைக்கும் இதைச் செய்வது மதிப்புள்ளது.

அல்லது DynamicUser உடன் கணக்கை முற்றிலும் தவிர்க்கவும்

systemd ஒரு படி மேலே சென்று உங்களுக்காக ஒரு தற்காலிக பயனரை உருவாக்க முடியும், அது சேவை இயங்கும்போது மட்டுமே இருக்கும். DynamicUser=yes ஐ அமைத்தால் நீங்கள் ஒரு கணக்கையும் நிர்வகிக்க மாட்டீர்கள்:

[Service]
ExecStart=/opt/myapp/bin/server
DynamicUser=yes
StateDirectory=myapp

தொடங்கும்போது, systemd பயன்படுத்தப்படாத ஒரு user ID ஐ ஒதுக்குகிறது; நிறுத்தும்போது, அது அதை விடுவிக்கிறது. சேவை ஒரு தனிப்பட்ட /tmp, filesystem இன் பெரும்பாலானவற்றின் read-only பார்வை, மற்றும் /var/lib/myapp கீழ் ஒரு எழுதக்கூடிய state directory ஆகியவற்றையும் பெறுகிறது, இதை StateDirectory= அமைத்து அதற்கு கொடுக்கிறது. தனது state directory மட்டுமே தேவைப்படும் தன்னிறைவான சேவைக்கு, DynamicUser=yes என்பது வலுவான தனிமைப்படுத்தலைப் பெற குறைந்த முயற்சி வழியாகும், ஏனெனில் தாக்குபவர் இலக்கு வைக்க நீண்ட காலம் வாழும் கணக்கு எதுவுமே இல்லை.

கைமுறையாக unit களை எழுதுவது சிரமமானது, மேலும் hardening directives ஐ சரியாகப் பெறுவதுதான் பெரும்பாலான மதிப்பு. systemd சேவை மற்றும் timer வழிகாட்டியில் உள்ள generator இந்த விருப்பங்களை உங்களுக்காக நிரப்ப முடியும், எனவே unit முதல் முறையே சரியாக இருக்கும்.

இது மீதமுள்ளவற்றுடன் எவ்வாறு பொருந்துகிறது

குறைந்தபட்ச அதிகாரம் ஒரு அடுக்கு, மேலும் இது மற்றவற்றை மாற்றுவதற்கு பதிலாக அவற்றுடன் சேர்ந்து வேலை செய்கிறது. ஒரு default-deny firewall சேவையை எது அடைய முடியும் என்பதை கட்டுப்படுத்துகிறது; அதிகாரம் இல்லாத பயனராக இயக்குவது மீறப்பட்டால் சேவை என்ன செய்ய முடியும் என்பதை கட்டுப்படுத்துகிறது; மேலும் hardened SSH தாக்குபவர்களை முதலிலேயே இயந்திரத்திற்கு வெளியே வைக்கிறது. இவற்றில் எதுவும் தனியாக போதுமானது அல்ல, மேலும் ஒன்றாக சேர்ந்து அவை ஒரு சேவையில் உள்ள பிழை முழு சேவையகத்தின் மீறலாக மாறாது என்பதை உறுதிசெய்கின்றன.

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

FAQ

நான் ஒரு சேவையை root ஆக ஏன் இயக்கக்கூடாது?

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

உள்நுழைய முடியாத ஒரு பயனரை நான் எப்படி உருவாக்குவது?

sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME ஐ இயக்குங்கள். nologin shell என்பது அதன் சான்றாணைகள் திருடப்பட்டாலும் கணக்கால் ஒரு interactive session ஐ திறக்க முடியாது என்பதாகும், --system அதை சேவை கணக்காக குறிக்கிறது, மேலும் --no-create-home தேவையில்லாத home directory ஐ தவிர்க்கிறது. chown உடன் அதற்கு அதன் சொந்த கோப்புகளின் உரிமையை மட்டும் கொடுங்கள்.

systemd DynamicUser என்றால் என்ன?

DynamicUser=yes என்பது systemd க்கு சேவைக்காக ஒரு தற்காலிக பயனரை உருவாக்கச் சொல்கிறது, அது இயங்கும்போது மட்டுமே இருக்கும், எனவே நீங்கள் ஒருபோதும் நீண்ட காலம் வாழும் கணக்கை நிர்வகிக்க மாட்டீர்கள். இது சேவைக்கு ஒரு தனிப்பட்ட /tmp, பெரும்பாலும் read-only filesystem பார்வை, மற்றும் ஒரு நிர்வகிக்கப்படும் state directory ஆகியவற்றையும் கொடுக்கிறது. இது ஒரு தற்காலிக, குறைந்த-அதிகார அடையாளத்தின் கீழ் தன்னிறைவான சேவையை இயக்குவதற்கான குறைந்த முயற்சி வழியாகும்.

ஒரு non-root பயனராக இயக்குவது ஒரு firewall ஐ மாற்றுமா?

இல்லை. அவை வெவ்வேறு விஷயங்களைப் பாதுகாக்கின்றன. அதிகாரம் இல்லாத பயனராக இயக்குவது சேவை மீறப்பட்டால் அது என்ன செய்ய முடியும் என்பதை வரம்பிடுகிறது, அதேசமயம் firewall சேவையை எது அடைய முடியும் என்பதை வரம்பிடுகிறது. hardened SSH உடன் இரண்டையும் பயன்படுத்துங்கள், எனவே ஒவ்வொரு அடுக்கும் மற்றவை முடியாதவற்றை மூடுகிறது.

சேவை பயனருக்கு எந்த கோப்புகள் சொந்தமாக இருக்க வேண்டும்?

சேவை உண்மையில் தேவைப்படும் கோப்புகள் மட்டுமே, அதற்கு மேல் ஒன்றுமில்லை. கணக்கிற்கு அதன் சொந்த வேலை directory மற்றும் அதன் தரவின் உரிமையை மட்டும் கொடுங்கள், மேலும் மற்ற அனைத்தையும் root க்கு சொந்தமானதாக விட்டுவிடுங்கள். ஒரு நல்ல முறை பயன்பாட்டு directory க்கு sudo chown -R svc-app:svc-app /opt/svc-app, அதேசமயம் /etc கீழ் உள்ள உள்ளமைவு root க்கு சொந்தமானதாகவே இருக்கும், மேலும் சேவையால் படிக்க மட்டுமே முடியும். இலக்கு என்னவென்றால், process எப்போதாவது பாதிக்கப்பட்டால், அது மாற்றக்கூடிய கோப்புகள் அதன் சொந்த தரவிற்கு மட்டும் கட்டுப்படுத்தப்படுகின்றன, கணினியின் மீதமுள்ளவை அல்ல.