Linux-ல் services-ஐ unprivileged user-ஆக இயக்குவது எப்படி?

ஏன் அனைத்தையும் root பயனர் மூலம் இயக்கக்கூடாது

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

இதுவே 'principle of least privilege' ஆகும்: கணினியின் ஒவ்வொரு பகுதிக்கும் அதன் வேலைக்குத் தேவையான குறைந்தபட்ச அணுகலை மட்டுமே வழங்க வேண்டும், அதற்கு மேல் எதையும் வழங்கக்கூடாது. ஒரு பாதுகாப்பு மீறல் (compromise) ஏற்படும்போது அதன் பாதிப்பைக் குறைக்க இதுவே மிகச் சிறந்த வழியாகும். நவீன server-களில் இதைச் செயல்படுத்துவதற்கு எந்த கூடுதல் செலவோ அல்லது சிரமமோ இல்லை.

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

ஒவ்வொரு சேவைக்கும் தனித்தனி system user-ஐ உருவாக்குவது ஒரு சிறந்த அணுகுமுறையாகும். இந்த பயனர் அந்த சேவைக்கான கோப்புகளை மட்டுமே சொந்தமாகக் கொண்டிருப்பார், மேலும் அவரால் கணினியில் உள்நுழைய (login) முடியாது. ஒரு இணைய செயலிக்கான (web app) system account பின்வருமாறு இருக்கலாம்:

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-ஐ மட்டுமே வாசிக்கவும் எழுதவும் முடியும், வட்டில் (disk) வேறு எங்கும் அதற்கு அனுமதி இருக்காது. ஒருவேளை அந்த சேவை ஊடுருவப்பட்டால், தாக்குபவரால் மாற்றக்கூடிய கோப்புகள் /opt/myapp-க்குள் மட்டுமே கட்டுப்படுத்தப்படும்; அந்த கணக்கினால் உலகளாவிய வாசிப்பு அனுமதி (world-readable) கொண்ட கோப்புகளை வாசிக்க முடியுமே தவிர, கணினியின் பிற பகுதிகளை மாற்ற முடியாது.

அந்த பயனர் கணக்கின் கீழ் systemd-ஐ இயக்கவும்

பயனர் கணக்கு உருவாக்கப்பட்ட பிறகு, அந்த கணக்கின் கீழ் service-ஐ இயக்குமாறு systemd-க்கு கட்டளையிட வேண்டும். Unit file-ல், இதற்கான ஒரு வரியைச் சேர்க்கவும்:

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

User=appsvc என்பது, root-ன் அதிகாரங்களுக்குப் பதிலாக, குறிப்பிட்ட பயனர் கணக்கின் வரையறுக்கப்பட்ட அதிகாரங்களுடன் process தொடங்குவதை உறுதி செய்கிறது. systemd-ன் கீழ் ஒரு application-ஐ இயக்குவதற்கு இதுவே சரியான மற்றும் வழக்கமான முறையாகும்; நீங்கள் எழுதும் ஒவ்வொரு service unit file-க்கும் இதைச் செய்வது அவசியம். இருப்பினும், systemd தவறான process-ஐ கண்காணித்துக் கொண்டிருந்தால், அதிகாரங்களைக் குறைப்பதால் (dropping privileges) எந்தப் பயனும் இருக்காது. எனவே, daemon அமைதியாக வெளியேறிய பிறகும் unit இன்னும் active என்று காட்டினால், உங்கள் process தொடங்கும் முறைக்கு ஏற்ற Type=-ஐத் தேர்ந்தெடுத்துள்ளீர்களா என்பதைச் சரிபார்க்கவும்.

DynamicUser மூலம் கணக்கை முழுமையாகத் தவிர்த்தல்

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

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

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

Unit கோப்புகளைக் கையால் எழுதுவது கடினமானது, மேலும் hardening directives-ஐச் சரியாக அமைப்பதே இதில் உள்ள முக்கியப் பயன். systemd service and timer guide-ல் உள்ள generator, இந்த விருப்பங்களை உங்களுக்காக நிரப்பித் தரும், இதன் மூலம் முதல் முறையிலேயே unit கோப்பு சரியாக அமையும்.

இது மற்றவற்றுடன் எவ்வாறு இணைகிறது

Least privilege என்பது ஒரு அடுக்கு மட்டுமே; இது மற்றவற்றை மாற்றுவதற்குப் பதிலாக அவற்றுடன் இணைந்து செயல்படுகிறது. ஒரு default-deny firewall சேவைக்கு எவை வரலாம் என்பதைக் கட்டுப்படுத்துகிறது; ஒரு சேவையை unprivileged user-ஆக இயக்குவது, அது breached செய்யப்பட்டால் அந்தச் சேவை என்ன செய்ய முடியும் என்பதைக் கட்டுப்படுத்துகிறது; மேலும் hardened SSH தாக்குதல் நடத்துபவர்கள் முதலில் server-க்குள் நுழைவதைத் தடுக்கிறது. இவற்றில் எதுவுமே தனித்தனியாகப் போதுமானதல்ல; இவை அனைத்தும் ஒன்றாகச் செயல்படும்போது, ஒரு சேவையில் உள்ள பிழை முழு server-ம் சமரசமாவதைத் தடுக்கிறது. ரகசியங்களைப் பாதுகாக்கும் ஒன்றை host செய்யும்போது இந்த அடுக்குகள் எங்கே முடிகின்றன என்பது தெளிவாகிறது: ஒரு restricted account, breached செய்யப்பட்ட process எதைத் தொடலாம் என்பதைக் கட்டுப்படுத்துகிறது. ஆனால், Vaultwarden போன்ற ஒரு self-hosted password manager-ன் பாதுகாப்பு, அதன் admin token மற்றும் backup file-ஐ நீங்கள் எவ்வாறு பாதுகாக்கிறீர்கள் என்பதைப் பொறுத்தே அமைகிறது; இவை இரண்டையும் user isolation முறை பாதுகாப்பதில்லை.

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

FAQ

ஒரு service-ஐ root பயனர் மூலம் ஏன் இயக்கக்கூடாது?

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

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

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

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

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

root அல்லாத பயனர் மூலம் இயக்குவது firewall-க்கு மாற்றாகுமா?

இல்லை. இவை இரண்டும் வெவ்வேறு பாதுகாப்பு அம்சங்களை வழங்குகின்றன. ஒரு service-ல் பாதிப்பு ஏற்பட்டால், அது என்ன செய்ய முடியும் என்பதை unprivileged பயனர் கட்டுப்படுத்துகிறார். அதே சமயம், அந்த service-ஐ எது அணுக முடியும் என்பதை firewall கட்டுப்படுத்துகிறது. எனவே, இரண்டையும் பயன்படுத்தவும். அத்துடன், பாதுகாப்பான SSH முறையையும் பின்பற்றுவதன் மூலம், ஒவ்வொரு அடுக்கிலும் மற்றொன்று செய்ய முடியாத பாதுகாப்பை உறுதிப்படுத்தலாம்.

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

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