paano i-run ang service bilang unprivileged user

Bakit hindi na lang i-run ang lahat bilang root

Kaya ng root ang kahit ano sa machine: basahin ang bawat file, baguhin ang anumang setting, o burahin ang buong system. Kapag ni-run mo ang isang service bilang root, ibinibigay mo ang lahat ng kapangyarihang iyon sa service na iyon. Kung may bug ang service na maaaring i-exploit ng attacker, hindi lang ang service ang makukuha nila, kundi pati ang root, at ang root ay ang buong server. Ang pagtakbo bilang unprivileged user ay naglilimita sa pinsala. Ang bug sa isang service na tumatakbo bilang limited account ay nagbibigay lamang sa attacker ng kung ano ang pwedeng galawin ng account na iyon, na dapat ay halos wala lang.

Ito ang principle of least privilege: bigyan ang bawat bahagi ng system ng eksaktong access na kailangan nito para sa trabaho nito, at wala nang iba pa. Ito ang pinaka-epektibong paraan para limitahan ang blast radius ng isang compromise, at sa isang modernong server, halos wala itong gastos sa pag-apply.

Isang dedicated account bawat service

Ang klasikong approach ay ang paggawa ng hiwalay na system user para sa bawat service, isang user na ang pagmamay-ari lang ay ang mga file ng service na iyon at hindi pwedeng mag-log in. Ang isang system account para sa isang web app ay maaaring ganito ang hitsura:

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

Mahalaga ang bawat flag. Ginagawa ng --system na service account ito, hindi human login. Ni-skip ng --no-create-home ang home directory na hindi naman kailangan. Ang --shell /usr/sbin/nologin ay nangangahulugang kahit makuha ng attacker ang account, hindi sila makakapag-open ng shell gamit ito. Ang account ay umiiral lamang para magmay-ari ng isang process at ng mga file nito.

Pagkatapos ay bigyan ang user na iyon ng mga file na kailangan lang nito, at wala nang iba pa:

sudo chown -R appsvc:appsvc /opt/myapp

Ngayon, binabasa at sinusulat ng service ang sarili nitong directory at wala itong pakialam sa ibang bahagi ng disk. Kung ma-exploit man ito, ang mga file na pwedeng baguhin ng attacker ay limitado lamang sa /opt/myapp; pwedeng pa ring basahin ng account ang anumang world-readable, pero hindi nito pwedeng baguhin ang natitirang bahagi ng system.

Hayaan ang systemd na i-run ito bilang user na iyon

Kapag umiiral na ang account, sabihan ang systemd na i-run ang service bilang user na iyon. Sa unit file, isang linya lang ang kailangan:

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

Ang User=appsvc ay nangangahulugang magsisimula ang process gamit ang limited privileges ng account na iyon sa halip na sa root. Ito ang normal at standard na paraan para magpatakbo ng application sa ilalim ng systemd, at dapat itong gawin para sa bawat service na gagawan mo ng unit.

O i-skip na lang ang account gamit ang DynamicUser

Maaaring higit pa ang gawin ng systemd at gumawa ng throwaway user para sa iyo, isang user na umiiral lamang habang tumatakbo ang service. I-set ang DynamicUser=yes at hindi mo na kailangang mag-manage ng account:

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

Sa simula, nag-aallocate ang systemd ng isang unused user ID; sa paghinto, ibinabalik ito. Ang service ay makakakuha rin ng private /tmp, isang read-only view ng karamihan sa filesystem, at isang writable state directory sa ilalim ng /var/lib/myapp na i-se-set up at ibibigay ng StateDirectory=. Para sa isang self-contained service na kailangan lang ang sarili nitong state directory, ang DynamicUser=yes ang pinakamadaling paraan para makakuha ng malakas na isolation, dahil wala namang long-lived account na pwedeng targetin ng attacker.

Ang pagsusulat ng mga unit nang manual ay mahirap, at ang tamang pag-set ng hardening directives ang pinaka-importante. Ang generator sa systemd service and timer guide ay pwedeng maglagay ng mga option na ito para sa iyo para maging tama ang unit sa unang subok pa lang.

Paano ito pumapasok sa kabuuan

Ang least privilege ay isang layer, at gumagana ito kasama ang iba pang layers sa halip na palitan ang mga ito. Ang isang default-deny firewall ang kumokontrol sa kung ano ang pwedeng makarating sa service; ang pagtakbo nito bilang unprivileged user ang kumokontrol sa kung ano ang pwedeng gawin ng service kung ito ay ma-breach; at ang hardened SSH ang pumipigil sa mga attacker na makapasok sa box sa simula pa lang. Walang iisang layer ang sapat, at kapag magkakasama sila, ang bug sa isang service ay hindi magiging sanhi ng compromise ng buong server.

Bago magpatuloy, i-run ang isang hardening checklist para sa buong box at gumawa ng personalized copy para magamit:

FAQ

Bakit hindi ko dapat i-run ang isang service bilang root?

Dahil ang root ay pwedeng gumawa ng kahit ano sa machine, ang isang service na tumatakbo bilang root na ma-exploit ay magbibigay sa attacker ng buong server, hindi lang ang service. Ang pagtakbo ng service bilang isang limited, unprivileged account ay naglilimita sa pinsala sa kung ano lang ang pwedeng ma-access ng account na iyon. Ireserba ang root para sa administration, at i-run ang bawat long-running service bilang isang restricted user.

Paano ako gagawa ng user na hindi pwedeng mag-log in?

I-run ang sudo useradd --system --no-create-home --shell /usr/sbin/nologin NAME. Ang nologin shell ay nangangahulugang hindi pwedeng mag-open ng interactive session ang account kahit manakaw ang credentials nito, ang --system ay nagmamarka dito bilang isang service account, at ang --no-create-home ay nag-i-skip ng home directory na hindi naman kailangan. Bigyan ito ng ownership sa sarili nitong mga file gamit ang chown.

Ano ang systemd DynamicUser?

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

Ang pagtakbo ba bilang non-root user ay kapalit na ng firewall?

Hindi. Iba ang proteksyon ng mga ito. Ang pagtakbo bilang unprivileged user ay naglilimita sa kung ano ang pwedeng gawin ng isang service kung ito ay ma-breach, habang ang firewall naman ay naglilimita sa kung ano ang pwedeng makarating sa service. Gamitin ang pareho, kasama ang hardened SSH, para ang bawat layer ay sakop ang hindi kayang sakop ng iba.

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

Ang mga file lang na kailangan talaga ng service, at wala nang iba pa. Bigyan ang account ng ownership sa sarili nitong working directory at sa data nito, at iwanan ang lahat ng iba pang file na pagmamay-ari ng root. Ang isang magandang pattern ay sudo chown -R svc-app:svc-app /opt/svc-app para sa application directory, habang ang configuration sa ilalim ng /etc ay dapat manatiling pagmamay-ari ng root at readable lang ng service. Ang layunin ay kung ma-compromise man ang process, ang mga file na pwedeng baguhin nito ay limitado lang sa sarili nitong data, hindi sa natitirang bahagi ng system.