Jinsi ya kuendesha huduma kama mtumiaji wa kawaida

Kwa nini usitumie root kuendesha kila kitu

Root ina uwezo wa kufanya chochote kwenye mashine: kusoma faili yoyote, kubadilisha mipangilio yoyote, na kufuta mfumo mzima. Unapoendesha huduma kama root, unakabidhi uwezo huo wote kwa huduma hiyo. Ikiwa huduma hiyo ina hitilafu ambayo mshambuliaji anaweza kuitumia, hawapati huduma hiyo pekee, bali wanapata root, na root ndiyo seva nzima. Kuendesha huduma kama mtumiaji asiye na upendeleo (unprivileged user) kunadhibiti uharibifu. Hitilafu katika huduma inayoendeshwa kama akaunti yenye mipaka humpa mshambuliaji kile tu ambacho akaunti hiyo inaweza kukigusa, ambacho kimsingi kinapaswa kuwa hakuna kitu.

Hii ndiyo kanuni ya upendeleo mdogo (principle of least privilege): ipe kila sehemu ya mfumo ufikiaji unaohitajika tu ili kutekeleza kazi yake, na si zaidi ya hapo. Hii ndiyo tabia bora zaidi ya kupunguza wigo wa uharibifu wakati wa uvamizi, na kwenye seva ya kisasa, haikugharimu chochote kuitumia.

Akaunti maalum kwa kila huduma

Mbinu ya kawaida ni kuunda mtumiaji wa mfumo (system user) tofauti kwa kila huduma, ambaye anamiliki faili za huduma hiyo pekee na hawezi kuingia kwenye mfumo (login). Akaunti ya mfumo kwa ajili ya programu ya wavuti inaweza kuonekana hivi:

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

Kila flag ina umuhimu wake. --system huifanya akaunti hiyo kuwa ya huduma, si ya mtumiaji wa kawaida. --no-create-home huruka saraka ya nyumbani (home directory) ambayo haihitajiki. --shell /usr/sbin/nologin inamaanisha kuwa hata kama mshambuliaji akipata uwezo wa kutumia akaunti hiyo, hawezi kufungua shell nayo. Akaunti hiyo ipo kwa ajili ya kumiliki mchakato (process) na faili zake pekee.

Kisha, mpe mtumiaji huyo faili anazohitaji pekee, na si zaidi ya hapo:

sudo chown -R appsvc:appsvc /opt/myapp

Sasa huduma hiyo inasoma na kuandika kwenye saraka yake yenyewe na haina ruhusa ya kufanya chochote kwingine kwenye diski. Ikiwa itawahi kudukuliwa, faili ambazo mshambuliaji anaweza kuzibadilisha zimepunguzwa hadi /opt/myapp; akaunti hiyo bado inaweza kusoma chochote kinachoruhusiwa kusomwa na kila mtu (world-readable), lakini haiwezi kurekebisha sehemu nyingine ya mfumo.

Acha systemd iendeshe huduma hiyo kama mtumiaji huyo

Mara tu akaunti hiyo inapokuwepo, iambie systemd iendeshe huduma hiyo kwa kutumia akaunti hiyo. Kwenye faili ya unit, mstari mmoja hufanya kazi hii:

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

User=appsvc inamaanisha mchakato huanza na haki ndogo za akaunti hiyo badala ya zile za root. Hii ndiyo njia ya kawaida na iliyothibitishwa ya kuendesha programu chini ya systemd, na inafaa kufanywa kwa kila huduma unayoiandikia faili ya unit. Hata hivyo, kupunguza haki hakutasaidia ikiwa systemd inafuatilia mchakato usio sahihi; kwa hivyo, ikiwa unit bado inaripoti kuwa active baada ya daemon kusimama kimya kimya, hakikisha kuwa umechagua Type= sahihi kwa namna mchakato wako unavyoanza.

Au ruka akaunti kabisa kwa kutumia DynamicUser

systemd inaweza kwenda hatua moja zaidi na kukuundia mtumiaji wa muda, ambaye yupo tu wakati huduma inafanya kazi. Weka DynamicUser=yes na hutahitaji kusimamia akaunti yoyote:

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

Wakati wa kuanza, systemd hutenga kitambulisho cha mtumiaji (user ID) kisichotumika; wakati wa kusimama, hukitoa. Huduma hiyo pia hupata /tmp binafsi, mtazamo wa kusoma pekee (read-only) wa sehemu kubwa ya mfumo wa faili, na saraka ya hali (state directory) inayoweza kuandikika chini ya /var/lib/myapp ambayo StateDirectory= huiandaa na kuikabidhi. Hakuna kitu kama hiki kilichowezekana chini ya SysV init, ambapo kupunguza mamlaka (dropping privileges) kuliachwa kwa script yoyote ya kuanzisha huduma husika, na pengo hilo ni sehemu kubwa ya kwa nini usambazaji wa Linux ulihamia kwenye systemd hapo awali. Kwa huduma inayojitegemea ambayo inahitaji tu saraka yake ya hali, DynamicUser=yes ndiyo njia rahisi zaidi ya kupata utengano (isolation) thabiti, kwa sababu hakuna akaunti ya kudumu ambayo mshambuliaji anaweza kuilenga.

Kuandika unit kwa mkono ni kazi ngumu, na kupata maelekezo sahihi ya kuimarisha usalama (hardening directives) ndiyo thamani kuu. Jenereta iliyo katika mwongozo wa systemd service na timer inaweza kukujazia chaguzi hizi ili unit iwe sahihi katika jaribio la kwanza.

Jinsi hii inavyoendana na mengine

Kanuni ya upendeleo mdogo (least privilege) ni safu moja, na inafanya kazi pamoja na nyingine badala ya kuzichukua nafasi zao. Firewall ya default-deny hudhibiti kile kinachoweza kufikia huduma; kuiendesha kama mtumiaji asiye na upendeleo (unprivileged user) hudhibiti kile ambacho huduma inaweza kufanya ikivamiwa; na SSH iliyoimarishwa (hardened SSH) huwazuia washambuliaji kuingia kwenye seva kwanza. Hakuna hata moja kati ya hizi inayotosha pekee yake, na kwa pamoja zinahakikisha kuwa hitilafu katika huduma moja haisababishi kuvamiwa kwa seva nzima. Kuendesha kitu kinacholinda siri (secrets) kunaonyesha mahali ambapo safu hizi zinaishia: akaunti iliyozuiliwa hupunguza kile ambacho mchakato uliovamiwa unaweza kugusa, lakini password manager inayojiendesha kama Vaultwarden bado inategemea jinsi unavyolinda token yake ya utawala na faili yake ya backup, ambazo zote hazilindwi na utengaji wa mtumiaji (user isolation).

Kabla ya kuendelea, pitia orodha ya ukaguzi wa usalama (hardening checklist) kwa seva nzima na utengeneze nakala iliyobinafsishwa ya kufanyia kazi:

FAQ

Kwa nini nisiiendeshe huduma kama root?

Kwa sababu root inaweza kufanya chochote kwenye mashine, huduma inayoendeshwa kama root ikivamiwa humpa mshambuliaji seva nzima, si huduma hiyo pekee. Kuendesha huduma kama akaunti ndogo isiyo na upendeleo huzuia uharibifu kwenye kile ambacho akaunti hiyo inaweza kufikia pekee. Hifadhi root kwa ajili ya usimamizi, na uendeshe kila huduma inayodumu kwa muda mrefu kama mtumiaji mwenye vikwazo.

Ninawezaje kuunda mtumiaji asiyeweza kuingia (log in)?

Endesha sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME. Shell ya nologin inamaanisha akaunti haiwezi kufungua session ya maingiliano hata kama vitambulisho vyake vikiibwa, --system inaitambulisha kama akaunti ya huduma, na --no-create-home inaruka saraka ya nyumbani (home directory) ambayo haihitaji. Ipe umiliki wa faili zake pekee kwa kutumia chown.

DynamicUser ya systemd ni nini?

DynamicUser=yes inaiambia systemd kuunda mtumiaji wa muda kwa ajili ya huduma ambaye yupo tu wakati huduma hiyo inafanya kazi, kwa hivyo huna haja ya kusimamia akaunti ya kudumu. Pia inapa huduma hiyo /tmp ya faragha, mtazamo wa mfumo wa faili ambao ni wa kusoma tu (read-only), na saraka ya hali (state directory) inayodhibitiwa. Hii ndiyo njia rahisi zaidi ya kuendesha huduma inayojitegemea chini ya utambulisho wa muda mfupi na wenye upendeleo mdogo.

Je, kuendesha kama mtumiaji asiye root kunachukua nafasi ya firewall?

Hapana. Hivi hulinda vitu tofauti. Kuendesha kama mtumiaji asiye na upendeleo hupunguza kile huduma inaweza kufanya ikivamiwa, wakati firewall hupunguza kile kinachoweza kufikia huduma hiyo kabisa. Tumia vyote viwili, pamoja na SSH iliyoimarishwa, ili kila safu ifunike kile ambacho nyingine haiwezi.

Ni faili zipi mtumiaji wa huduma anapaswa kumiliki?

Faili ambazo huduma inahitaji tu, na si nyingine. Ipe akaunti hiyo umiliki wa saraka yake ya kazi na data zake, na uache kila kitu kingine kimilikiwe na root. Mfumo mzuri ni sudo chown -R svc-app:svc-app /opt/svc-app kwa saraka ya programu, wakati usanidi (configuration) chini ya /etc unabaki kumilikiwa na root na unaweza kusomwa na huduma hiyo pekee. Lengo ni kwamba mchakato huo ukivamiwa, faili ambazo inaweza kubadilisha ziwe na kikomo kwenye data zake pekee, si mfumo mzima.