Paano Patakbuhin ang Service Bilang Unprivileged User

Bakit hindi na lang patakbuhin ang lahat bilang root

Kayang gawin ng root ang anumang bagay sa machine: basahin ang bawat file, baguhin ang anumang setting, at burahin ang buong system. Kapag nagpatakbo ka ng service bilang root, ibinibigay mo sa service na iyon ang lahat ng kapangyarihang ito. Kung may bug ang service na maaaring pagsamantalahan ng attacker, hindi lang nila makukuha ang service; makukuha rin nila ang root, at ang root ang may ganap na access sa buong server. Ang pagpapatakbo bilang unprivileged user ay naglilimita sa pinsala. Kung may bug ang service na tumatakbo gamit ang limited account, ang makukuha ng attacker ay ang mga resource lamang na maa-access ng account na iyon, na dapat ay halos wala.

Ito ang principle of least privilege: ibigay sa bawat bahagi ng system ang eksaktong access na kailangan nito para magawa ang tungkulin nito, at wala nang iba. Ito ang pinakamabisang gawi para limitahan ang lawak ng pinsalang dulot ng isang breach, at sa modern server, halos walang gastos ang pagpapatupad nito.

Isang dedicated account para sa bawat serbisyo

Ang klasikong approach ay gumawa ng hiwalay na system user para sa bawat serbisyo. Ang user na ito ang nagmamay-ari lamang ng mga file ng serbisyong iyon at hindi maaaring mag-login. Maaaring ganito ang system account para sa isang web app:

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

Mahalaga ang bawat flag. Ginagawa itong service account ng --system, hindi human login. Nilalaktawan ng --no-create-home ang home directory na hindi nito kailangan. Ibig sabihin ng --shell /usr/sbin/nologin, kahit mapasakamay ng attacker ang account, hindi ito magagamit upang magbukas ng shell. Umiiral lamang ang account upang magmay-ari ng isang process at ng mga file nito.

Pagkatapos, ibigay sa user na iyon ang mga file na kailangan lamang nito:

sudo chown -R appsvc:appsvc /opt/myapp

Ngayon, nagbabasa at nagsusulat ang serbisyo sa sarili nitong directory at wala itong kailangan sa iba pang bahagi ng disk. Kung ma-exploit man ito, limitado sa /opt/myapp ang mga file na maaaring baguhin ng attacker. Makakabasa pa rin ang account ng anumang file na world-readable, pero hindi nito mababago ang natitirang bahagi ng system.

Patakbuhin ito ng systemd bilang user na iyon

Kapag mayroon na ang account, sabihin sa systemd na patakbuhin ang service bilang user na iyon. Sa unit file, isang linya lang ang kailangan:

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

Nangangahulugan ang User=appsvc na magsisimula ang process gamit ang limitadong privilege ng account na iyon sa halip na privilege ng root. Ito ang karaniwan at subok na paraan ng pagpapatakbo ng application sa systemd. Dapat mo itong gawin para sa bawat service na gagawan mo ng unit. Gayunman, hindi makatutulong ang pag-drop ng privilege kung maling process ang mino-monitor ng systemd. Kaya kung active pa rin ang ulat ng unit kahit tahimik nang lumabas ang daemon, tingnan kung napili mo ang tamang Type= para sa paraan ng pagsisimula ng iyong process.

O laktawan ang account gamit ang DynamicUser

Maaari pang gumawa ang systemd ng pansamantalang user para sa iyo. Umiiral lamang ang user habang tumatakbo ang service. Itakda ang DynamicUser=yes upang hindi mo na kailangang mag-manage ng account:

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

Sa pagsisimula, naglalaan ang systemd ng hindi pa ginagamit na user ID. Sa paghinto, binabawi nito ang ID. Nakakakuha rin ang service ng pribadong /tmp, read-only view ng karamihan sa filesystem, at writable state directory sa ilalim ng /var/lib/myapp na ise-setup at ipapasa rito ng StateDirectory=. Hindi ito posible sa SysV init, kung saan nakadepende ang privilege dropping sa ginagawa ng sariling start script ng bawat service. Malaking bahagi ng agwat na ito ang dahilan kung bakit lumipat ang mga distribution sa systemd. Para sa self-contained service na sarili nitong state directory lamang ang kailangan, ang DynamicUser=yes ang pinakamadaling paraan upang makamit ang matibay na isolation. Wala kasing persistent account na maaaring targetin ng attacker.

Mahirap isulat nang mano-mano ang mga unit. Karamihan ng halaga ay nasa tamang pag-configure ng hardening directives. Maaaring awtomatikong punan ng generator sa guide para sa systemd service at timer ang mga opsyong ito upang maging tama ang unit sa unang paggawa pa lamang.

Paano ito kaugnay ng iba pang layer

Ang least privilege ay isang layer lamang, at nakikipagtulungan ito sa iba pang layer sa halip na palitan ang mga ito. Kinokontrol ng isang firewall na default-deny kung ano ang maaaring makaabot sa serbisyo; kinokontrol naman ng pagpapatakbo nito bilang unprivileged user kung ano ang magagawa ng serbisyo kapag na-breach ito; at pinipigilan ng pinatibay na SSH na makapasok ang mga attacker sa server. Hindi sapat ang alinman sa mga ito kapag nag-iisa. Kapag pinagsama, hindi agad nagiging compromise ng buong server ang bug sa isang serbisyo. Ipinapakita ng pagho-host ng serbisyong nagpoprotekta ng mga secret kung saan nagtatapos ang mga layer na ito: nililimitahan ng restricted account ang maaaring galawin ng na-breach na proseso, ngunit nakasalalay pa rin ang self-hosted password manager gaya ng Vaultwarden sa paraan ng pagprotekta mo sa admin token at backup file nito. Hindi saklaw ng user isolation ang alinman sa dalawang ito.

Bago magpatuloy, gamitin ang hardening checklist para sa buong server at bumuo ng personalized na kopyang gagamitin mo:

FAQ

Bakit hindi dapat magpatakbo ng service bilang root?

Dahil kayang gawin ng root ang anumang bagay sa machine, kapag na-exploit ang service na tumatakbo bilang root, buong server ang napupunta sa attacker, hindi lamang ang service. Kung patatakbuhin ang service bilang limitado at walang pribilehiyong account, nalilimitahan ang pinsala sa mga resource na maa-access ng account na iyon. Gamitin lamang ang root para sa administration, at patakbuhin ang bawat long-running service bilang restricted user.

Paano ako gagawa ng user na hindi makakapag-log in?

Patakbuhin ang sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME. Ibig sabihin ng nologin shell na hindi makakapagbukas ang account ng interactive session kahit manakaw ang credentials nito, minamarkahan ito ng --system bilang service account, at nilalaktawan ng --no-create-home ang home directory na hindi nito kailangan. Ibigay rito ang ownership ng sarili lamang nitong mga file gamit ang chown.

Ano ang systemd DynamicUser?

Inuutusan ng DynamicUser=yes ang systemd na gumawa ng temporary user para sa service na umiiral lamang habang tumatakbo ito, kaya hindi mo kailangang mag-manage ng long-lived account. Binibigyan din nito ang service ng private /tmp, mostly read-only na filesystem view, at managed state directory. Ito ang pinakamadaling paraan para magpatakbo ng self-contained service gamit ang temporary, low-privilege identity.

Napapalitan ba ng pagpapatakbo bilang non-root user ang firewall?

Hindi. Magkaibang bagay ang pinoprotektahan ng mga ito. Nililimitahan ng pagpapatakbo bilang unprivileged user ang maaaring gawin ng service kapag na-breach ito, samantalang nililimitahan ng firewall kung ano ang makakaabot sa service. Gamitin ang dalawa, kasama ang hardened SSH, para matakpan ng bawat layer ang mga hindi kayang protektahan ng iba.

Anong mga file ang dapat pagmamay-ari ng service user?

Tanging ang mga file na talagang kailangan ng service, at wala nang iba. Ibigay sa account ang ownership ng sarili nitong working directory at data, at panatilihing pagmamay-ari ng root ang lahat ng iba pa. Magandang pattern ang sudo chown -R svc-app:svc-app /opt/svc-app para sa application directory, habang ang configuration sa ilalim ng /etc ay nananatiling pagmamay-ari ng root at read-only lamang para sa service. Ang layunin ay kapag na-compromise ang process, limitado sa sarili nitong data ang mga file na maaari nitong baguhin, at hindi kasama ang natitirang bahagi ng system.