：普通用戶執(zhí)行root腳本的sudo與setuid全解析)
我是一個(gè)在服務(wù)器上折騰了七八年的老運(yùn)維今天想好好聊聊 Linux 權(quán)限管理里一個(gè)非常實(shí)用、但也經(jīng)常被搞出安全問(wèn)題的操作如何讓普通用戶安全執(zhí)行 root 權(quán)限的特定腳本。很多人一遇到“普通用戶要執(zhí)行管理員操作”的需求第一反應(yīng)就是給賬號(hào)加 sudo甚至直接把用戶加進(jìn) sudoers 白名單。但這在真實(shí)的生產(chǎn)環(huán)境里其實(shí)是個(gè)很危險(xiǎn)的做法。我見(jiàn)過(guò)不止一次因?yàn)?sudo 權(quán)限給得太寬一條誤操作命令直接把線上服務(wù)搞掛或者把系統(tǒng)文件權(quán)限改亂。今天這篇文章我就結(jié)合自己踩過(guò)的坑把sudo 規(guī)則精確授權(quán)、setuid 位、策略執(zhí)行封裝、以及幾種安全兜底方案全部拆開(kāi)講清楚。不管你是剛?cè)胄械倪\(yùn)維新人還是已經(jīng)帶團(tuán)隊(duì)的老手這套思路都值得收藏。文章會(huì)從需求分析開(kāi)始講清楚什么時(shí)候該用哪種方案再給出具體可復(fù)制的配置示例最后把我實(shí)際運(yùn)維中遇到的高頻問(wèn)題排查經(jīng)驗(yàn)也一并分享出來(lái)。內(nèi)容偏實(shí)操適合對(duì) Linux 用戶權(quán)限、腳本執(zhí)行、安全基線有一定基礎(chǔ)但又想更進(jìn)一步理解“最小權(quán)限原則”怎么落地的朋友。1. 需求拆解你到底需要哪種“臨時(shí)提權(quán)”很多朋友一上來(lái)就問(wèn)“怎么讓普通用戶執(zhí)行 root 腳本”但實(shí)際需求往往分成好幾類。如果需求沒(méi)拆清楚后面方案選型就會(huì)很混亂。1.1 四種最常見(jiàn)的真實(shí)場(chǎng)景我在實(shí)際工作中遇到過(guò)這么幾種典型情況基本覆蓋了絕大多數(shù)“普通用戶需要 root 能力”的需求場(chǎng)景 A運(yùn)維腳本定期執(zhí)行。比如每天凌晨要跑一個(gè)備份腳本腳本里需要讀取只有 root 能訪問(wèn)的配置文件或者需要操作系統(tǒng)級(jí)別的日志目錄。這個(gè)腳本是固定的、內(nèi)容可控的普通用戶不會(huì)去改它。場(chǎng)景 B業(yè)務(wù)程序需要特定系統(tǒng)調(diào)用。比如某個(gè)監(jiān)控采集程序需要讀取其他用戶進(jìn)程的 CPU 內(nèi)存占用或者需要綁定低端口。這類程序是編譯好的二進(jìn)制普通用戶直接運(yùn)行會(huì)報(bào)權(quán)限錯(cuò)誤。場(chǎng)景 C開(kāi)發(fā)同學(xué)需要重啟某個(gè)服務(wù)。團(tuán)隊(duì)里開(kāi)發(fā)人員經(jīng)常需要重啟 Web 服務(wù)、查看服務(wù)狀態(tài)但又不應(yīng)該讓他們隨意改系統(tǒng)配置、看其他敏感文件。場(chǎng)景 D完全不確定腳本內(nèi)容只是想讓某個(gè)用戶“能執(zhí)行管理員操作”。這種情況最危險(xiǎn)也最不建議直接授權(quán)。1.2 選型前必須先想清楚的三件事在確定技術(shù)方案之前我建議你先問(wèn)自己三個(gè)問(wèn)題第一腳本內(nèi)容是否完全可信如果這個(gè)腳本會(huì)被普通用戶編輯或者腳本內(nèi)部會(huì)動(dòng)態(tài)拼接命令那么任何形式的提權(quán)都是在給你的系統(tǒng)開(kāi)門(mén)。一旦腳本被注入惡意命令等于把 root 權(quán)限直接交了出去。第二提權(quán)范圍是“單條命令”還是“整套流程”如果只是執(zhí)行一個(gè)固定的二進(jìn)制程序用 sudo 精確到程序路徑就夠了。如果需要執(zhí)行一個(gè)腳本但腳本內(nèi)部又會(huì)調(diào)用其他命令那這些被調(diào)用的命令也必須在授權(quán)范圍之內(nèi)否則 sudo 會(huì)攔截失敗。第三這個(gè)權(quán)限是長(zhǎng)期有效還是臨時(shí)借用長(zhǎng)期有效的需求適合 sudoers 精確配置或者 sudo 封裝腳本。臨時(shí)借用可以考慮一次性授權(quán)、或者運(yùn)維平臺(tái)臨時(shí)審批。提示任何時(shí)候都不要為了圖省事直接把普通用戶加入 root 組或者給一個(gè)ALL(ALL) ALL的 sudo 規(guī)則。這基本等于把系統(tǒng)管理員權(quán)限復(fù)制了一份給業(yè)務(wù)用戶出了事連審計(jì)日志都很難定位。想清楚這三點(diǎn)之后下面這些具體方案才有意義。否則你只是把一個(gè)危險(xiǎn)的權(quán)限換了一種危險(xiǎn)的給法。2. 最穩(wěn)妥的日常方案sudoers 精確規(guī)則授權(quán)sudo 是 Linux 系統(tǒng)自帶的提權(quán)工具本身設(shè)計(jì)得很安全但前提是你得會(huì)用。絕大多數(shù)安全問(wèn)題都是因?yàn)橐?guī)則寫(xiě)得太大、太模糊。2.1 sudoers 文件應(yīng)該怎么改sudo 的配置文件在/etc/sudoers正規(guī)做法是不要直接編輯這個(gè)文件而是用visudo命令。visudo 會(huì)在保存前做語(yǔ)法檢查如果格式寫(xiě)錯(cuò)它會(huì)阻止你保存避免搞出“sudo 全線不可用”的悲劇。我習(xí)慣在/etc/sudoers.d/目錄下為不同需求單獨(dú)建文件。比如給某個(gè)運(yùn)維用戶授權(quán)重啟 Web 服務(wù)我會(huì)新建一個(gè)/etc/sudoers.d/web-admin內(nèi)容如下# 允許 user1 以 root 身份無(wú)密碼執(zhí)行 systemctl restart nginx user1 ALL(root) NOPASSWD: /usr/bin/systemctl restart nginx這里解釋一下每一段的含義user1被授權(quán)的用戶名。ALL允許該用戶從任何主機(jī)登錄執(zhí)行也可以限制為某個(gè)內(nèi)網(wǎng) IP后面我會(huì)講。(root)允許切換到的目標(biāo)用戶身份是 root。NOPASSWD:執(zhí)行時(shí)不需要再輸入密碼。如果去掉這項(xiàng)執(zhí)行時(shí)需要輸入用戶自己的密碼安全性更高一點(diǎn)但頻繁操作時(shí)會(huì)比較煩。最后一段具體允許執(zhí)行的命令和參數(shù)。參數(shù)必須寫(xiě)完整否則 sudo 會(huì)按模糊匹配處理存在被繞過(guò)風(fēng)險(xiǎn)。2.2 腳本授權(quán)的兩種寫(xiě)法別用錯(cuò)如果普通用戶需要執(zhí)行的是一個(gè)腳本文件而不是系統(tǒng)命令sudoers 的寫(xiě)法就要格外小心。正確寫(xiě)法推薦user1 ALL(root) NOPASSWD: /usr/local/bin/backup.sh這種寫(xiě)法授權(quán)的是“執(zhí)行這個(gè)腳本文件本身”。腳本內(nèi)部調(diào)用什么命令sudo 不會(huì)再管。所以前提是腳本內(nèi)容可信、且普通用戶不能編輯它。錯(cuò)誤寫(xiě)法千萬(wàn)別用user1 ALL(root) NOPASSWD: /bin/sh /usr/local/bin/backup.sh這種寫(xiě)法的意思是“允許以 root 身份執(zhí)行/bin/sh并且參數(shù)是 backup.sh”。但問(wèn)題在于sudo 對(duì)參數(shù)的控制非常弱用戶完全可以換成/bin/sh /etc/passwd或者任意其他文件甚至直接執(zhí)行/bin/sh進(jìn)入一個(gè) root shell。等于你把一把萬(wàn)能鑰匙給了別人鎖還沒(méi)換。2.3 關(guān)鍵參數(shù)command 部分為什么必須寫(xiě)到底sudoers 的一個(gè)核心設(shè)計(jì)就是“絕對(duì)路徑 完整參數(shù)”。我給你舉個(gè)我真實(shí)見(jiàn)過(guò)的反面例子。某團(tuán)隊(duì)在 sudoers 里寫(xiě)了這樣一行dev ALL(root) NOPASSWD: /usr/bin/systemctl restart nginx注意這里是/usr/bin/systemctl restart nginx沒(méi)有通配符看起來(lái)挺安全。但實(shí)際上問(wèn)題不在這一行而在于 dev 用戶還可以執(zhí)行其他 systemctl 子命令嗎不會(huì)sudo 會(huì)攔截。真正的問(wèn)題出在如果腳本路徑寫(xiě)得是/usr/bin/systemctl *那用戶就能執(zhí)行systemctl stop firewalld、systemctl disable sshd甚至systemctl reboot。這就不再是“允許重啟 Nginx”了而是“允許管理系統(tǒng)上所有服務(wù)”。所以我的經(jīng)驗(yàn)是sudoers 里的命令路徑全部寫(xiě)絕對(duì)路徑參數(shù)不允許出現(xiàn)通配符除非你非常清楚自己在做什么。另外建議定期用sudo -l查看當(dāng)前用戶的 sudo 權(quán)限確認(rèn)實(shí)際授權(quán)范圍。2.4 限制來(lái)源 IP 和登錄方式如果你的服務(wù)器有運(yùn)維跳板機(jī)或者只允許內(nèi)網(wǎng)訪問(wèn)那么 sudoers 里最好也把來(lái)源地址限制住。例如user1 192.168.10.0/24(root) NOPASSWD: /usr/local/bin/backup.sh這樣即使跳板機(jī)被攻破攻擊者也只能從該網(wǎng)段發(fā)起提權(quán)至少多了一層限制。另外很多系統(tǒng)管理員喜歡給普通用戶配置 SSH 密鑰登錄后再配合 sudo 使用。我建議普通用戶的 SSH 登錄盡量禁止 root 直接登錄而是用普通用戶登錄后按需使用受限 sudo 執(zhí)行任務(wù)。這樣審計(jì)日志里能明確看到是誰(shuí)、在哪臺(tái)機(jī)器、用了哪條 sudo 命令。3. 讓普通用戶執(zhí)行“你自己的腳本”sudo 策略封裝有時(shí)候你需要普通用戶執(zhí)行的不只是一個(gè)簡(jiǎn)單命令而是你自己寫(xiě)的一整套運(yùn)維腳本腳本里有大量邏輯判斷、命令調(diào)用和日志輸出。這種情況下直接用 sudo 授權(quán)腳本本身雖然可行但審計(jì)和管理都不太方便。我來(lái)分享一個(gè)更可控的封裝思路把需要提權(quán)的操作寫(xiě)成獨(dú)立腳本再通過(guò) sudo 只暴露一個(gè)“入口 wrapper”最后在 wrapper 里做二次校驗(yàn)。3.1 一個(gè)典型的“備份提權(quán) wrapper”示例假設(shè)我們要實(shí)現(xiàn)普通用戶 user1 可以執(zhí)行/opt/scripts/backup_system.sh這個(gè)腳本內(nèi)部會(huì)調(diào)用tar、rsync、systemctl等命令。第一步先寫(xiě)好真正的提權(quán)腳本路徑設(shè)置為 root 所有# /opt/scripts/backup_system.sh #!/bin/bash set -euo pipefail LOG_FILE/var/log/backup_$(date %F_%H%M).log echo [$(date)] backup start $LOG_FILE tar -czf /backup/web.tar.gz /var/www/html rsync -av /backup/ user1backup-server:/backup/ systemctl reload nginx echo [$(date)] backup done $LOG_FILE第二步在 sudoers 里授權(quán)這個(gè) wrapperuser1 ALL(root) NOPASSWD: /opt/scripts/backup_system.sh第三步普通用戶執(zhí)行sudo /opt/scripts/backup_system.sh這樣做的好處是普通用戶只能執(zhí)行這一個(gè)入口無(wú)法直接調(diào)用內(nèi)部的 tar、rsync 或 systemctl。即使他臨時(shí)想看腳本內(nèi)容也沒(méi)問(wèn)題但沒(méi)有執(zhí)行權(quán)限去改腳本。我們?cè)侔涯_本文件權(quán)限設(shè)置成 root:rootchmod 750普通用戶可以執(zhí)行但不可寫(xiě)安全性大大提高。3.2 腳本內(nèi)部安全性不要讓命令參數(shù)被用戶拼接有人可能會(huì)問(wèn)如果我在腳本里支持用戶傳入?yún)?shù)比如指定備份目錄那 sudo 授權(quán)還能安全嗎答案是可以但必須非常小心。最常見(jiàn)的安全漏洞是“參數(shù)注入”。例如腳本這么寫(xiě)#!/bin/bash tar -czf /backup/web.tar.gz $1用戶執(zhí)行sudo /opt/scripts/backup_system.sh /var/www/html; rm -rf /如果腳本里沒(méi)有對(duì)參數(shù)做校驗(yàn)就會(huì)出現(xiàn)災(zāi)難。我的建議是對(duì)于底層腳本盡可能不接收用戶原始輸入。如果必須接收也要做嚴(yán)格的白名單校驗(yàn)比如只允許目錄路徑位于某個(gè)固定前綴下并且過(guò)濾掉所有特殊字符。具體可以用正則匹配if [[ $1 ~ ^/var/www/[a-zA-Z0-9_/-]$ ]]; then : else echo invalid path 2 exit 1 fi3.3 為什么我強(qiáng)烈建議“普通用戶不可寫(xiě)腳本”很多人為了圖方便把提權(quán)腳本放到用戶家目錄或者權(quán)限設(shè)置成了 777。這是大忌。試想一下如果普通用戶可以修改這個(gè)提權(quán)腳本那他就等于可以修改“以 root 身份運(yùn)行的邏輯”。他只要在腳本里加一行useradd attacker或者chmod 777 /etc/shadow下一次執(zhí)行 sudo 腳本時(shí)就是以 root 權(quán)限完成了惡意操作。所以腳本文件本身必須是 root 擁有權(quán)限至少750最好700然后通過(guò) sudo 規(guī)則單獨(dú)授權(quán)給指定用戶。這樣普通用戶只有“執(zhí)行權(quán)”沒(méi)有“修改權(quán)”。注意如果你用 sudo 執(zhí)行的是一個(gè) shell 腳本sudo 的secure_path配置也要檢查一下。/etc/sudoers里默認(rèn)有secure_path它決定了 sudo 環(huán)境下 PATH 內(nèi)容。如果腳本內(nèi)調(diào)用的命令路徑在默認(rèn) PATH 之外腳本會(huì)執(zhí)行失敗或者從用戶自定義 PATH 中加載惡意同名命令。建議在腳本開(kāi)頭寫(xiě)死命令絕對(duì)路徑或者保持系統(tǒng)默認(rèn) PATH。4. 少用但必須會(huì)setuid 位與輔助工具對(duì)比除了 sudoLinux 下還有幾種可以讓普通用戶執(zhí)行特權(quán)程序的辦法包括 setuid 位、pkexec、以及通過(guò)守護(hù)進(jìn)程調(diào)用。它們各自有適用場(chǎng)景也有明顯的坑。4.1 setuid 位是什么什么時(shí)候能用setuid 位是一個(gè)特殊的文件權(quán)限位。當(dāng)一個(gè)可執(zhí)行文件設(shè)置了 setuid 位那么任何用戶執(zhí)行這個(gè)文件時(shí)進(jìn)程的有效用戶 ID 會(huì)臨時(shí)變成文件屬主。如果文件屬主是 root普通用戶運(yùn)行它時(shí)這個(gè)進(jìn)程就擁有了 root 權(quán)限。舉個(gè)例子/usr/bin/passwd就是典型的 setuid 程序普通用戶能用它修改自己的密碼而修改密碼需要寫(xiě)/etc/shadow普通用戶本身沒(méi)有這個(gè)權(quán)限。我們也可以設(shè)置自己的腳本chmod 4755 /opt/scripts/backup_system.sh但這里有個(gè)大坑對(duì)于 shell 腳本Linux 內(nèi)核出于安全考慮在很多發(fā)行版上會(huì)忽略 setuid 位。也就是說(shuō)你給.sh文件設(shè)置4755運(yùn)行時(shí)仍然是以調(diào)用者的權(quán)限執(zhí)行的根本不會(huì)生效。只有編譯后的二進(jìn)制程序比如 C 程序才能可靠使用 setuid 位。如果確實(shí)要使用 setuid需要把邏輯寫(xiě)進(jìn)一個(gè)編譯好的 C 小工具里然后把這個(gè)工具以 root:root 權(quán)限部署。比如#include stdio.h #include stdlib.h #include unistd.h int main() { setuid(0); system(/opt/scripts/backup_system.sh); return 0; }然后編譯、設(shè)置 root 屬主、加 setuid 位gcc -o backup_helper backup_helper.c sudo chown root:root backup_helper sudo chmod 4755 backup_helper這種方式可以用但審計(jì)性不如 sudo。setuid 程序執(zhí)行時(shí)不會(huì)像 sudo 那樣在/var/log/auth.log里留下誰(shuí)執(zhí)行了哪條命令的記錄。所以一般情況下我不會(huì)推薦 setuid 作為首選。4.2 sudo 和 setuid 的對(duì)比到底選誰(shuí)從安全性、可維護(hù)性、審計(jì)能力三個(gè)維度看sudo 完勝 setuid。對(duì)比項(xiàng)sudo 精確規(guī)則setuid 程序?qū)徲?jì)日志有詳細(xì)日志基本沒(méi)有權(quán)限控制粒度可按用戶、主機(jī)、命令、參數(shù)控制只能按文件授權(quán)維護(hù)難度改 sudoers 即可需要改源碼重新編譯誤用風(fēng)險(xiǎn)低規(guī)則寫(xiě)好后高容易被惡意利用適用場(chǎng)景絕大多數(shù)運(yùn)維管理需求極少場(chǎng)景比如專用系統(tǒng)工具我見(jiàn)過(guò)有些團(tuán)隊(duì)為了追求“不用輸入密碼”就把核心運(yùn)維命令封裝成 setuid 程序結(jié)果出了問(wèn)題根本查不到是誰(shuí)什么時(shí)候執(zhí)行的。后面換成 sudo NOPASSWD雖然還是不用輸密碼但至少日志完整。4.3 pkexec 和守護(hù)進(jìn)程方案簡(jiǎn)述除了 sudo 和 setuid還有兩個(gè)方案值得知道。pkexec是 PolicyKit 的命令行工具。它可以在桌面上彈出授權(quán)框或者根據(jù) polkit 規(guī)則允許指定用戶執(zhí)行某條命令。相比 sudopkexec 的規(guī)則寫(xiě)在/usr/share/polkit-1/actions/和/etc/polkit-1/rules.d/里配置方式更現(xiàn)代化。但實(shí)際運(yùn)維中很多服務(wù)器沒(méi)有桌面環(huán)境pkexec 的交互體驗(yàn)不如 sudo 順滑。守護(hù)進(jìn)程方案是把需要 root 權(quán)限的操作封裝成系統(tǒng)服務(wù)普通用戶通過(guò)調(diào)用服務(wù)的控制接口來(lái)觸發(fā)。比如可以寫(xiě)一個(gè) root 權(quán)限的 systemd service普通用戶只能通過(guò)systemctl --user里的某個(gè)受限接口提交任務(wù)后臺(tái)再由代理執(zhí)行。這種方式最安全、審計(jì)最完整但實(shí)現(xiàn)成本也最高。適合企業(yè)級(jí)運(yùn)維平臺(tái)的場(chǎng)景比如批量發(fā)布、日志清理、定期巡檢這類高頻操作。5. 實(shí)戰(zhàn)演示完整配置一個(gè)“普通用戶可執(zhí)行 root 備份腳本”前面講了不少理論現(xiàn)在我來(lái)走一遍完整流程。從零開(kāi)始把需求變成最終可用的配置你照著操作就能在自己環(huán)境里復(fù)現(xiàn)。5.1 需求定義我們希望實(shí)現(xiàn)以下目標(biāo)普通用戶ops可以執(zhí)行/opt/scripts/db_backup.sh。該腳本會(huì)以 root 權(quán)限執(zhí)行數(shù)據(jù)庫(kù)備份、壓縮、移動(dòng)到備份目錄。普通用戶不能查看數(shù)據(jù)庫(kù)密碼文件不能修改備份腳本。執(zhí)行過(guò)程需要輸入 ops 用戶的密碼以增加審計(jì)安全。所有 sudo 調(diào)用都能在系統(tǒng)日志中查到。5.2 環(huán)境準(zhǔn)備與腳本創(chuàng)建假設(shè)系統(tǒng)是常見(jiàn)的 Linux 發(fā)行版默認(rèn)帶 sudo、bash。創(chuàng)建腳本目錄并寫(xiě)腳本sudo mkdir -p /opt/scripts sudo tee /opt/scripts/db_backup.sh /dev/null EOF #!/bin/bash set -euo pipefail BACKUP_DIR/backup/mysql DATE$(date %F_%H%M) mkdir -p $BACKUP_DIR # 這里是模擬備份命令實(shí)際生產(chǎn)環(huán)境請(qǐng)使用真實(shí)數(shù)據(jù)庫(kù)備份工具 tar -czf $BACKUP_DIR/db_$DATE.tar.gz /var/lib/mysql find $BACKUP_DIR -type f -mtime 7 -delete echo [$(date)] backup completed: $BACKUP_DIR/db_$DATE.tar.gz EOF然后設(shè)置屬主和權(quán)限sudo chown root:root /opt/scripts/db_backup.sh sudo chmod 750 /opt/scripts/db_backup.sh到這一步普通用戶 ops 即使能看到腳本也無(wú)法編輯它。5.3 創(chuàng)建普通用戶并配置 sudo 規(guī)則創(chuàng)建用戶 ops并加入需要的輔助組比如 ops 可能需要讀取某些日志但這不是必須的sudo useradd -m ops sudo passwd ops然后創(chuàng)建獨(dú)立的 sudoers 配置文件sudo visudo -f /etc/sudoers.d/ops-backup在打開(kāi)的編輯器里寫(xiě)入ops ALL(root) /opt/scripts/db_backup.sh注意我這里沒(méi)有加 NOPASSWD意思是執(zhí)行時(shí)需要輸入 ops 自己的密碼。寫(xiě)入后保存。驗(yàn)證語(yǔ)法sudo visudo -c如果輸出parsed OK就說(shuō)明配置沒(méi)問(wèn)題。5.4 普通用戶實(shí)際操作驗(yàn)證切換到 ops 用戶進(jìn)行驗(yàn)證sudo -u ops -i sudo /opt/scripts/db_backup.sh第一次會(huì)提示輸入 ops 的密碼輸入后腳本執(zhí)行。如果希望驗(yàn)證腳本內(nèi)部命令是否還需要額外授權(quán)可以在腳本里直接寫(xiě)一個(gè)需要 root 權(quán)限的操作比如touch /root/test_backup_marker然后在腳本中執(zhí)行。當(dāng)普通用戶運(yùn)行 sudo 腳本時(shí)腳本內(nèi)部已經(jīng)是 root 身份所以這個(gè) touch 也能成功。這就是 sudo 包裝腳本的特權(quán)傳播特性。如果要查看執(zhí)行記錄可以查看sudo tail -f /var/log/auth.log或者在使用 journald 的系統(tǒng)上journalctl -u sudo -f你會(huì)看到類似ops : TTYpts/0 ; PWD/home/ops ; USERroot ; COMMAND/opt/scripts/db_backup.sh的記錄。提示如果腳本里有一些命令不在默認(rèn) PATH 中一定要在腳本開(kāi)頭export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin避免 sudo 環(huán)境下找不到命令。5.5 權(quán)限收緊如何避免 ops 看到敏感文件有些腳本內(nèi)容本身會(huì)包含數(shù)據(jù)庫(kù)密碼普通用戶一旦可讀就等于泄露。更安全的做法是將腳本設(shè)為僅 root 可讀可執(zhí)行sudo chmod 700 /opt/scripts/db_backup.sh但這樣的話普通用戶還能執(zhí)行嗎答案是可以因?yàn)?sudo 是以 root 身份執(zhí)行這個(gè)腳本的。sudo 在執(zhí)行命令前不要求執(zhí)行者對(duì)腳本有讀取權(quán)限因?yàn)閳?zhí)行者是 rootroot 能讀取一切文件。所以如果普通用戶根本不需要了解腳本內(nèi)容設(shè)置700是最佳選擇。這樣即使有人查看腳本內(nèi)容也看不到敏感數(shù)據(jù)。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這部分是我真正在日常運(yùn)維中驗(yàn)證過(guò)的內(nèi)容很多坑如果不踩一遍光看文檔是發(fā)現(xiàn)不了的。6.1 用戶執(zhí)行時(shí)報(bào)錯(cuò)“對(duì)不起用戶 xxxx 無(wú)權(quán)以 root 的身份執(zhí)行”這個(gè)報(bào)錯(cuò)最常見(jiàn)的原因是 sudoers 規(guī)則沒(méi)匹配上。檢查幾個(gè)地方用戶名是否正確。命令路徑是否完全絕對(duì)路徑。是否存在其他更早的 sudoers 規(guī)則覆蓋。是否在/etc/sudoers.d/下創(chuàng)建了文件但文件權(quán)限不對(duì)。sudoers.d 下的文件必須屬主 root權(quán)限440否則 sudo 會(huì)直接忽略并在日志里提示權(quán)限不正確。修復(fù)方式sudo chown root:root /etc/sudoers.d/ops-backup sudo chmod 440 /etc/sudoers.d/ops-backup sudo visudo -c6.2 腳本本身能直接執(zhí)行但 sudo 執(zhí)行時(shí)報(bào)“找不到命令”這是因?yàn)?sudo 有secure_path默認(rèn)可能不含/usr/local/bin或/opt/scripts。兩個(gè)解決方案方案一腳本內(nèi)寫(xiě)全絕對(duì)路徑。比如把tar寫(xiě)成/bin/tar。方案二修改 sudoers 的 secure_path。比如在/etc/sudoers里增加Defaults secure_path/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/scripts我更推薦方案一因?yàn)檫@樣腳本不依賴 sudo 環(huán)境變量可移植性更好。6.3 sudo 執(zhí)行腳本不生效狀態(tài)碼 126 或 127126 通常表示腳本文件沒(méi)有執(zhí)行權(quán)限。即使 root 能讀但內(nèi)核要執(zhí)行一個(gè)腳本解釋器必須能找到。檢查chmod x。127 通常表示解釋器不存在比如腳本第一行寫(xiě)了#!/usr/bin/python3但系統(tǒng)里沒(méi)有 python3。用head -1 script.sh檢查。6.4 普通用戶執(zhí)行 sudo 腳本時(shí)腳本內(nèi)部又調(diào)用 sudo 導(dǎo)致死循環(huán)像我前面寫(xiě)的腳本如果腳本內(nèi)部有sudo systemctl reload nginx而腳本本身已經(jīng)是用 root 身份運(yùn)行的那么就會(huì)變成“root 用戶再 sudo 到 root”有時(shí)候會(huì)觸發(fā) sudo 的惡意命令拒絕策略。解決辦法很簡(jiǎn)單腳本內(nèi)部不要再寫(xiě) sudo因?yàn)檎麄€(gè)腳本已經(jīng)運(yùn)行在 root shell 下。直接寫(xiě)systemctl reload nginx即可。6.5 怎么臨時(shí)給某用戶一次性授權(quán)如果只是讓某用戶執(zhí)行一次特定命令可以在 sudoers 中臨時(shí)加一條帶時(shí)間限制的規(guī)則但 sudo 本身沒(méi)有“過(guò)期時(shí)間”功能。更實(shí)用的做法是使用運(yùn)維平臺(tái)的臨時(shí)授權(quán)接口或者簡(jiǎn)單粗暴地在用戶執(zhí)行完命令后馬上刪除 sudoers 文件。我個(gè)人的習(xí)慣是給 sudoers 文件按用途命名并備注日期。比如ops-temporary-backup-20250101執(zhí)行完畢后立即刪除sudo rm /etc/sudoers.d/ops-temporary-backup-20250101這樣即使有審計(jì)也能清楚看到什么時(shí)間段開(kāi)了什么權(quán)限。6.6 檢查當(dāng)前用戶實(shí)際擁有哪些 sudo 權(quán)限作為運(yùn)維人員我經(jīng)常需要快速確認(rèn)某個(gè)賬號(hào)到底能執(zhí)行什么。方法很簡(jiǎn)單sudo -l -U ops這會(huì)列出所有和 ops 相關(guān)的 sudo 規(guī)則。如果輸出太多可以針對(duì)用戶看sudo -lU ops這個(gè)命令在排查“為什么用戶能執(zhí)行某條命令”時(shí)非常有用能直接看到最終生效的規(guī)則是哪一條。7. 安全加固別讓授權(quán)變成后門(mén)最后再聊幾個(gè)我踩過(guò)的安全細(xì)節(jié)這些很容易被忽略但影響非常大。7.1 小心 sudo 包裝腳本里的“環(huán)境變量注入”腳本如果使用了用戶可控的環(huán)境變量比如$PATH、$LD_PRELOAD、$PYTHONPATH就可能被利用。舉個(gè)最簡(jiǎn)單的例子某腳本執(zhí)行tar但通過(guò)環(huán)境變量把tar指向惡意程序。解決方法是在腳本開(kāi)頭重置環(huán)境變量或者至少在sudoers里設(shè)置Defaults env_reset大多數(shù)發(fā)行版默認(rèn)已經(jīng)開(kāi)啟 env_reset但如果你自己改過(guò) sudoers就要確認(rèn)沒(méi)把它關(guān)掉。7.2 sudoers 規(guī)則順序越早匹配越優(yōu)先sudoers 規(guī)則是“先匹配先生效”。如果你有一個(gè)寬規(guī)則寫(xiě)在前面后面再寫(xiě)細(xì)規(guī)則也白搭。所以我的建議是顯式的精確規(guī)則永遠(yuǎn)寫(xiě)在最前面兜底規(guī)則寫(xiě)在最后。比如避免寫(xiě)這樣的寬規(guī)則ops ALL(root) NOPASSWD: /usr/bin/*這種規(guī)則等于開(kāi)放了整個(gè)/usr/bin下所有命令危害極大。如果你確實(shí)需要通配也要縮小到具體目錄和具體不可繞過(guò)的二進(jìn)制。7.3 審計(jì)提醒定期檢查 sudo 日志我習(xí)慣每周花五分鐘快速掃一下 auth.log 里的 sudo 記錄重點(diǎn)看有沒(méi)有異常頻率的提權(quán)操作。如果發(fā)現(xiàn)某賬號(hào)在凌晨頻繁執(zhí)行 sudo即使規(guī)則看起來(lái)沒(méi)問(wèn)題也要排查是不是賬號(hào)被濫用。日志查看方法sudo grep sudo /var/log/auth.log | tail -100在 journald 系統(tǒng)上journalctl _COMMsudo --since 7 days ago如果不想手動(dòng)看也可以簡(jiǎn)單寫(xiě)個(gè) cron 任務(wù)把 sudo 日志匯總發(fā)到運(yùn)維群。但這塊屬于擴(kuò)展內(nèi)容今天先不展開(kāi)。8. 最后的個(gè)人經(jīng)驗(yàn)如果你問(wèn)我這幾年在權(quán)限管理上最大的體會(huì)我覺(jué)得就一句話權(quán)限最小化絕不是一句口號(hào)而是每一次配置都要落到具體路徑、具體參數(shù)、具體用戶上。sudo 本身很強(qiáng)大強(qiáng)大到可以一句話就讓你擁有整個(gè)系統(tǒng)的權(quán)限也可以強(qiáng)大到只讓你執(zhí)行一個(gè)嚴(yán)格校驗(yàn)過(guò)的備份腳本。差別就在于你愿不愿意花那幾分鐘去寫(xiě)清楚規(guī)則。另外還有一個(gè)容易被忽視的點(diǎn)腳本的可維護(hù)性和權(quán)限管理同樣重要。我見(jiàn)過(guò)太多團(tuán)隊(duì)花大力氣把 sudo 規(guī)則寫(xiě)得滴水不漏但提權(quán)腳本本身寫(xiě)得一塌糊涂命令到處用相對(duì)路徑變量不校驗(yàn)出了問(wèn)題沒(méi)人敢改。久而久之這些“安全”的規(guī)則就變成了定時(shí)炸彈。所以我的建議是提權(quán)腳本要像生產(chǎn)代碼一樣對(duì)待版本管理、代碼評(píng)審、權(quán)限控制一個(gè)都不能少。這樣配合 sudo 精確規(guī)則才能形成一個(gè)真正可靠的權(quán)限體系。如果你現(xiàn)在正好有一個(gè)“普通用戶執(zhí)行 root 腳本”的需求我建議你從最小場(chǎng)景開(kāi)始先選一臺(tái)測(cè)試機(jī)寫(xiě)一個(gè)簡(jiǎn)單的腳本按我上面的步驟配置 sudoers然后用sudo -l -U 用戶名驗(yàn)證授權(quán)范圍再實(shí)際操作一遍。等你把這套流程跑通了再往生產(chǎn)環(huán)境推廣。這個(gè)順序能幫你避開(kāi)絕大多數(shù)低級(jí)事故。希望這篇文章能讓你少踩幾個(gè)坑。如果后續(xù)有機(jī)會(huì)我還會(huì)繼續(xù)分享關(guān)于 Linux 權(quán)限控制、自動(dòng)化運(yùn)維腳本設(shè)計(jì)、以及安全審計(jì)方面的一些實(shí)戰(zhàn)心得。 Linux安全提權(quán)：普通用戶執(zhí)行root腳本的sudo與setuid全解析
我是一個(gè)在服務(wù)器上折騰了七八年的老運(yùn)維今天想好好聊聊 Linux 權(quán)限管理里一個(gè)非常實(shí)用、但也經(jīng)常被搞出安全問(wèn)題的操作如何讓普通用戶安全執(zhí)行 root 權(quán)限的特定腳本。很多人一遇到“普通用戶要執(zhí)行管理員操作”的需求第一反應(yīng)就是給賬號(hào)加 sudo甚至直接把用戶加進(jìn) sudoers 白名單。但這在真實(shí)的生產(chǎn)環(huán)境里其實(shí)是個(gè)很危險(xiǎn)的做法。我見(jiàn)過(guò)不止一次因?yàn)?sudo 權(quán)限給得太寬一條誤操作命令直接把線上服務(wù)搞掛或者把系統(tǒng)文件權(quán)限改亂。今天這篇文章我就結(jié)合自己踩過(guò)的坑把sudo 規(guī)則精確授權(quán)、setuid 位、策略執(zhí)行封裝、以及幾種安全兜底方案全部拆開(kāi)講清楚。不管你是剛?cè)胄械倪\(yùn)維新人還是已經(jīng)帶團(tuán)隊(duì)的老手這套思路都值得收藏。文章會(huì)從需求分析開(kāi)始講清楚什么時(shí)候該用哪種方案再給出具體可復(fù)制的配置示例最后把我實(shí)際運(yùn)維中遇到的高頻問(wèn)題排查經(jīng)驗(yàn)也一并分享出來(lái)。內(nèi)容偏實(shí)操適合對(duì) Linux 用戶權(quán)限、腳本執(zhí)行、安全基線有一定基礎(chǔ)但又想更進(jìn)一步理解“最小權(quán)限原則”怎么落地的朋友。1. 需求拆解你到底需要哪種“臨時(shí)提權(quán)”很多朋友一上來(lái)就問(wèn)“怎么讓普通用戶執(zhí)行 root 腳本”但實(shí)際需求往往分成好幾類。如果需求沒(méi)拆清楚后面方案選型就會(huì)很混亂。1.1 四種最常見(jiàn)的真實(shí)場(chǎng)景我在實(shí)際工作中遇到過(guò)這么幾種典型情況基本覆蓋了絕大多數(shù)“普通用戶需要 root 能力”的需求場(chǎng)景 A運(yùn)維腳本定期執(zhí)行。比如每天凌晨要跑一個(gè)備份腳本腳本里需要讀取只有 root 能訪問(wèn)的配置文件或者需要操作系統(tǒng)級(jí)別的日志目錄。這個(gè)腳本是固定的、內(nèi)容可控的普通用戶不會(huì)去改它。場(chǎng)景 B業(yè)務(wù)程序需要特定系統(tǒng)調(diào)用。比如某個(gè)監(jiān)控采集程序需要讀取其他用戶進(jìn)程的 CPU 內(nèi)存占用或者需要綁定低端口。這類程序是編譯好的二進(jìn)制普通用戶直接運(yùn)行會(huì)報(bào)權(quán)限錯(cuò)誤。場(chǎng)景 C開(kāi)發(fā)同學(xué)需要重啟某個(gè)服務(wù)。團(tuán)隊(duì)里開(kāi)發(fā)人員經(jīng)常需要重啟 Web 服務(wù)、查看服務(wù)狀態(tài)但又不應(yīng)該讓他們隨意改系統(tǒng)配置、看其他敏感文件。場(chǎng)景 D完全不確定腳本內(nèi)容只是想讓某個(gè)用戶“能執(zhí)行管理員操作”。這種情況最危險(xiǎn)也最不建議直接授權(quán)。1.2 選型前必須先想清楚的三件事在確定技術(shù)方案之前我建議你先問(wèn)自己三個(gè)問(wèn)題第一腳本內(nèi)容是否完全可信如果這個(gè)腳本會(huì)被普通用戶編輯或者腳本內(nèi)部會(huì)動(dòng)態(tài)拼接命令那么任何形式的提權(quán)都是在給你的系統(tǒng)開(kāi)門(mén)。一旦腳本被注入惡意命令等于把 root 權(quán)限直接交了出去。第二提權(quán)范圍是“單條命令”還是“整套流程”如果只是執(zhí)行一個(gè)固定的二進(jìn)制程序用 sudo 精確到程序路徑就夠了。如果需要執(zhí)行一個(gè)腳本但腳本內(nèi)部又會(huì)調(diào)用其他命令那這些被調(diào)用的命令也必須在授權(quán)范圍之內(nèi)否則 sudo 會(huì)攔截失敗。第三這個(gè)權(quán)限是長(zhǎng)期有效還是臨時(shí)借用長(zhǎng)期有效的需求適合 sudoers 精確配置或者 sudo 封裝腳本。臨時(shí)借用可以考慮一次性授權(quán)、或者運(yùn)維平臺(tái)臨時(shí)審批。提示任何時(shí)候都不要為了圖省事直接把普通用戶加入 root 組或者給一個(gè)ALL(ALL) ALL的 sudo 規(guī)則。這基本等于把系統(tǒng)管理員權(quán)限復(fù)制了一份給業(yè)務(wù)用戶出了事連審計(jì)日志都很難定位。想清楚這三點(diǎn)之后下面這些具體方案才有意義。否則你只是把一個(gè)危險(xiǎn)的權(quán)限換了一種危險(xiǎn)的給法。2. 最穩(wěn)妥的日常方案sudoers 精確規(guī)則授權(quán)sudo 是 Linux 系統(tǒng)自帶的提權(quán)工具本身設(shè)計(jì)得很安全但前提是你得會(huì)用。絕大多數(shù)安全問(wèn)題都是因?yàn)橐?guī)則寫(xiě)得太大、太模糊。2.1 sudoers 文件應(yīng)該怎么改sudo 的配置文件在/etc/sudoers正規(guī)做法是不要直接編輯這個(gè)文件而是用visudo命令。visudo 會(huì)在保存前做語(yǔ)法檢查如果格式寫(xiě)錯(cuò)它會(huì)阻止你保存避免搞出“sudo 全線不可用”的悲劇。我習(xí)慣在/etc/sudoers.d/目錄下為不同需求單獨(dú)建文件。比如給某個(gè)運(yùn)維用戶授權(quán)重啟 Web 服務(wù)我會(huì)新建一個(gè)/etc/sudoers.d/web-admin內(nèi)容如下# 允許 user1 以 root 身份無(wú)密碼執(zhí)行 systemctl restart nginx user1 ALL(root) NOPASSWD: /usr/bin/systemctl restart nginx這里解釋一下每一段的含義user1被授權(quán)的用戶名。ALL允許該用戶從任何主機(jī)登錄執(zhí)行也可以限制為某個(gè)內(nèi)網(wǎng) IP后面我會(huì)講。(root)允許切換到的目標(biāo)用戶身份是 root。NOPASSWD:執(zhí)行時(shí)不需要再輸入密碼。如果去掉這項(xiàng)執(zhí)行時(shí)需要輸入用戶自己的密碼安全性更高一點(diǎn)但頻繁操作時(shí)會(huì)比較煩。最后一段具體允許執(zhí)行的命令和參數(shù)。參數(shù)必須寫(xiě)完整否則 sudo 會(huì)按模糊匹配處理存在被繞過(guò)風(fēng)險(xiǎn)。2.2 腳本授權(quán)的兩種寫(xiě)法別用錯(cuò)如果普通用戶需要執(zhí)行的是一個(gè)腳本文件而不是系統(tǒng)命令sudoers 的寫(xiě)法就要格外小心。正確寫(xiě)法推薦user1 ALL(root) NOPASSWD: /usr/local/bin/backup.sh這種寫(xiě)法授權(quán)的是“執(zhí)行這個(gè)腳本文件本身”。腳本內(nèi)部調(diào)用什么命令sudo 不會(huì)再管。所以前提是腳本內(nèi)容可信、且普通用戶不能編輯它。錯(cuò)誤寫(xiě)法千萬(wàn)別用user1 ALL(root) NOPASSWD: /bin/sh /usr/local/bin/backup.sh這種寫(xiě)法的意思是“允許以 root 身份執(zhí)行/bin/sh并且參數(shù)是 backup.sh”。但問(wèn)題在于sudo 對(duì)參數(shù)的控制非常弱用戶完全可以換成/bin/sh /etc/passwd或者任意其他文件甚至直接執(zhí)行/bin/sh進(jìn)入一個(gè) root shell。等于你把一把萬(wàn)能鑰匙給了別人鎖還沒(méi)換。2.3 關(guān)鍵參數(shù)command 部分為什么必須寫(xiě)到底sudoers 的一個(gè)核心設(shè)計(jì)就是“絕對(duì)路徑 完整參數(shù)”。我給你舉個(gè)我真實(shí)見(jiàn)過(guò)的反面例子。某團(tuán)隊(duì)在 sudoers 里寫(xiě)了這樣一行dev ALL(root) NOPASSWD: /usr/bin/systemctl restart nginx注意這里是/usr/bin/systemctl restart nginx沒(méi)有通配符看起來(lái)挺安全。但實(shí)際上問(wèn)題不在這一行而在于 dev 用戶還可以執(zhí)行其他 systemctl 子命令嗎不會(huì)sudo 會(huì)攔截。真正的問(wèn)題出在如果腳本路徑寫(xiě)得是/usr/bin/systemctl *那用戶就能執(zhí)行systemctl stop firewalld、systemctl disable sshd甚至systemctl reboot。這就不再是“允許重啟 Nginx”了而是“允許管理系統(tǒng)上所有服務(wù)”。所以我的經(jīng)驗(yàn)是sudoers 里的命令路徑全部寫(xiě)絕對(duì)路徑參數(shù)不允許出現(xiàn)通配符除非你非常清楚自己在做什么。另外建議定期用sudo -l查看當(dāng)前用戶的 sudo 權(quán)限確認(rèn)實(shí)際授權(quán)范圍。2.4 限制來(lái)源 IP 和登錄方式如果你的服務(wù)器有運(yùn)維跳板機(jī)或者只允許內(nèi)網(wǎng)訪問(wèn)那么 sudoers 里最好也把來(lái)源地址限制住。例如user1 192.168.10.0/24(root) NOPASSWD: /usr/local/bin/backup.sh這樣即使跳板機(jī)被攻破攻擊者也只能從該網(wǎng)段發(fā)起提權(quán)至少多了一層限制。另外很多系統(tǒng)管理員喜歡給普通用戶配置 SSH 密鑰登錄后再配合 sudo 使用。我建議普通用戶的 SSH 登錄盡量禁止 root 直接登錄而是用普通用戶登錄后按需使用受限 sudo 執(zhí)行任務(wù)。這樣審計(jì)日志里能明確看到是誰(shuí)、在哪臺(tái)機(jī)器、用了哪條 sudo 命令。3. 讓普通用戶執(zhí)行“你自己的腳本”sudo 策略封裝有時(shí)候你需要普通用戶執(zhí)行的不只是一個(gè)簡(jiǎn)單命令而是你自己寫(xiě)的一整套運(yùn)維腳本腳本里有大量邏輯判斷、命令調(diào)用和日志輸出。這種情況下直接用 sudo 授權(quán)腳本本身雖然可行但審計(jì)和管理都不太方便。我來(lái)分享一個(gè)更可控的封裝思路把需要提權(quán)的操作寫(xiě)成獨(dú)立腳本再通過(guò) sudo 只暴露一個(gè)“入口 wrapper”最后在 wrapper 里做二次校驗(yàn)。3.1 一個(gè)典型的“備份提權(quán) wrapper”示例假設(shè)我們要實(shí)現(xiàn)普通用戶 user1 可以執(zhí)行/opt/scripts/backup_system.sh這個(gè)腳本內(nèi)部會(huì)調(diào)用tar、rsync、systemctl等命令。第一步先寫(xiě)好真正的提權(quán)腳本路徑設(shè)置為 root 所有# /opt/scripts/backup_system.sh #!/bin/bash set -euo pipefail LOG_FILE/var/log/backup_$(date %F_%H%M).log echo [$(date)] backup start $LOG_FILE tar -czf /backup/web.tar.gz /var/www/html rsync -av /backup/ user1backup-server:/backup/ systemctl reload nginx echo [$(date)] backup done $LOG_FILE第二步在 sudoers 里授權(quán)這個(gè) wrapperuser1 ALL(root) NOPASSWD: /opt/scripts/backup_system.sh第三步普通用戶執(zhí)行sudo /opt/scripts/backup_system.sh這樣做的好處是普通用戶只能執(zhí)行這一個(gè)入口無(wú)法直接調(diào)用內(nèi)部的 tar、rsync 或 systemctl。即使他臨時(shí)想看腳本內(nèi)容也沒(méi)問(wèn)題但沒(méi)有執(zhí)行權(quán)限去改腳本。我們?cè)侔涯_本文件權(quán)限設(shè)置成 root:rootchmod 750普通用戶可以執(zhí)行但不可寫(xiě)安全性大大提高。3.2 腳本內(nèi)部安全性不要讓命令參數(shù)被用戶拼接有人可能會(huì)問(wèn)如果我在腳本里支持用戶傳入?yún)?shù)比如指定備份目錄那 sudo 授權(quán)還能安全嗎答案是可以但必須非常小心。最常見(jiàn)的安全漏洞是“參數(shù)注入”。例如腳本這么寫(xiě)#!/bin/bash tar -czf /backup/web.tar.gz $1用戶執(zhí)行sudo /opt/scripts/backup_system.sh /var/www/html; rm -rf /如果腳本里沒(méi)有對(duì)參數(shù)做校驗(yàn)就會(huì)出現(xiàn)災(zāi)難。我的建議是對(duì)于底層腳本盡可能不接收用戶原始輸入。如果必須接收也要做嚴(yán)格的白名單校驗(yàn)比如只允許目錄路徑位于某個(gè)固定前綴下并且過(guò)濾掉所有特殊字符。具體可以用正則匹配if [[ $1 ~ ^/var/www/[a-zA-Z0-9_/-]$ ]]; then : else echo invalid path 2 exit 1 fi3.3 為什么我強(qiáng)烈建議“普通用戶不可寫(xiě)腳本”很多人為了圖方便把提權(quán)腳本放到用戶家目錄或者權(quán)限設(shè)置成了 777。這是大忌。試想一下如果普通用戶可以修改這個(gè)提權(quán)腳本那他就等于可以修改“以 root 身份運(yùn)行的邏輯”。他只要在腳本里加一行useradd attacker或者chmod 777 /etc/shadow下一次執(zhí)行 sudo 腳本時(shí)就是以 root 權(quán)限完成了惡意操作。所以腳本文件本身必須是 root 擁有權(quán)限至少750最好700然后通過(guò) sudo 規(guī)則單獨(dú)授權(quán)給指定用戶。這樣普通用戶只有“執(zhí)行權(quán)”沒(méi)有“修改權(quán)”。注意如果你用 sudo 執(zhí)行的是一個(gè) shell 腳本sudo 的secure_path配置也要檢查一下。/etc/sudoers里默認(rèn)有secure_path它決定了 sudo 環(huán)境下 PATH 內(nèi)容。如果腳本內(nèi)調(diào)用的命令路徑在默認(rèn) PATH 之外腳本會(huì)執(zhí)行失敗或者從用戶自定義 PATH 中加載惡意同名命令。建議在腳本開(kāi)頭寫(xiě)死命令絕對(duì)路徑或者保持系統(tǒng)默認(rèn) PATH。4. 少用但必須會(huì)setuid 位與輔助工具對(duì)比除了 sudoLinux 下還有幾種可以讓普通用戶執(zhí)行特權(quán)程序的辦法包括 setuid 位、pkexec、以及通過(guò)守護(hù)進(jìn)程調(diào)用。它們各自有適用場(chǎng)景也有明顯的坑。4.1 setuid 位是什么什么時(shí)候能用setuid 位是一個(gè)特殊的文件權(quán)限位。當(dāng)一個(gè)可執(zhí)行文件設(shè)置了 setuid 位那么任何用戶執(zhí)行這個(gè)文件時(shí)進(jìn)程的有效用戶 ID 會(huì)臨時(shí)變成文件屬主。如果文件屬主是 root普通用戶運(yùn)行它時(shí)這個(gè)進(jìn)程就擁有了 root 權(quán)限。舉個(gè)例子/usr/bin/passwd就是典型的 setuid 程序普通用戶能用它修改自己的密碼而修改密碼需要寫(xiě)/etc/shadow普通用戶本身沒(méi)有這個(gè)權(quán)限。我們也可以設(shè)置自己的腳本chmod 4755 /opt/scripts/backup_system.sh但這里有個(gè)大坑對(duì)于 shell 腳本Linux 內(nèi)核出于安全考慮在很多發(fā)行版上會(huì)忽略 setuid 位。也就是說(shuō)你給.sh文件設(shè)置4755運(yùn)行時(shí)仍然是以調(diào)用者的權(quán)限執(zhí)行的根本不會(huì)生效。只有編譯后的二進(jìn)制程序比如 C 程序才能可靠使用 setuid 位。如果確實(shí)要使用 setuid需要把邏輯寫(xiě)進(jìn)一個(gè)編譯好的 C 小工具里然后把這個(gè)工具以 root:root 權(quán)限部署。比如#include stdio.h #include stdlib.h #include unistd.h int main() { setuid(0); system(/opt/scripts/backup_system.sh); return 0; }然后編譯、設(shè)置 root 屬主、加 setuid 位gcc -o backup_helper backup_helper.c sudo chown root:root backup_helper sudo chmod 4755 backup_helper這種方式可以用但審計(jì)性不如 sudo。setuid 程序執(zhí)行時(shí)不會(huì)像 sudo 那樣在/var/log/auth.log里留下誰(shuí)執(zhí)行了哪條命令的記錄。所以一般情況下我不會(huì)推薦 setuid 作為首選。4.2 sudo 和 setuid 的對(duì)比到底選誰(shuí)從安全性、可維護(hù)性、審計(jì)能力三個(gè)維度看sudo 完勝 setuid。對(duì)比項(xiàng)sudo 精確規(guī)則setuid 程序?qū)徲?jì)日志有詳細(xì)日志基本沒(méi)有權(quán)限控制粒度可按用戶、主機(jī)、命令、參數(shù)控制只能按文件授權(quán)維護(hù)難度改 sudoers 即可需要改源碼重新編譯誤用風(fēng)險(xiǎn)低規(guī)則寫(xiě)好后高容易被惡意利用適用場(chǎng)景絕大多數(shù)運(yùn)維管理需求極少場(chǎng)景比如專用系統(tǒng)工具我見(jiàn)過(guò)有些團(tuán)隊(duì)為了追求“不用輸入密碼”就把核心運(yùn)維命令封裝成 setuid 程序結(jié)果出了問(wèn)題根本查不到是誰(shuí)什么時(shí)候執(zhí)行的。后面換成 sudo NOPASSWD雖然還是不用輸密碼但至少日志完整。4.3 pkexec 和守護(hù)進(jìn)程方案簡(jiǎn)述除了 sudo 和 setuid還有兩個(gè)方案值得知道。pkexec是 PolicyKit 的命令行工具。它可以在桌面上彈出授權(quán)框或者根據(jù) polkit 規(guī)則允許指定用戶執(zhí)行某條命令。相比 sudopkexec 的規(guī)則寫(xiě)在/usr/share/polkit-1/actions/和/etc/polkit-1/rules.d/里配置方式更現(xiàn)代化。但實(shí)際運(yùn)維中很多服務(wù)器沒(méi)有桌面環(huán)境pkexec 的交互體驗(yàn)不如 sudo 順滑。守護(hù)進(jìn)程方案是把需要 root 權(quán)限的操作封裝成系統(tǒng)服務(wù)普通用戶通過(guò)調(diào)用服務(wù)的控制接口來(lái)觸發(fā)。比如可以寫(xiě)一個(gè) root 權(quán)限的 systemd service普通用戶只能通過(guò)systemctl --user里的某個(gè)受限接口提交任務(wù)后臺(tái)再由代理執(zhí)行。這種方式最安全、審計(jì)最完整但實(shí)現(xiàn)成本也最高。適合企業(yè)級(jí)運(yùn)維平臺(tái)的場(chǎng)景比如批量發(fā)布、日志清理、定期巡檢這類高頻操作。5. 實(shí)戰(zhàn)演示完整配置一個(gè)“普通用戶可執(zhí)行 root 備份腳本”前面講了不少理論現(xiàn)在我來(lái)走一遍完整流程。從零開(kāi)始把需求變成最終可用的配置你照著操作就能在自己環(huán)境里復(fù)現(xiàn)。5.1 需求定義我們希望實(shí)現(xiàn)以下目標(biāo)普通用戶ops可以執(zhí)行/opt/scripts/db_backup.sh。該腳本會(huì)以 root 權(quán)限執(zhí)行數(shù)據(jù)庫(kù)備份、壓縮、移動(dòng)到備份目錄。普通用戶不能查看數(shù)據(jù)庫(kù)密碼文件不能修改備份腳本。執(zhí)行過(guò)程需要輸入 ops 用戶的密碼以增加審計(jì)安全。所有 sudo 調(diào)用都能在系統(tǒng)日志中查到。5.2 環(huán)境準(zhǔn)備與腳本創(chuàng)建假設(shè)系統(tǒng)是常見(jiàn)的 Linux 發(fā)行版默認(rèn)帶 sudo、bash。創(chuàng)建腳本目錄并寫(xiě)腳本sudo mkdir -p /opt/scripts sudo tee /opt/scripts/db_backup.sh /dev/null EOF #!/bin/bash set -euo pipefail BACKUP_DIR/backup/mysql DATE$(date %F_%H%M) mkdir -p $BACKUP_DIR # 這里是模擬備份命令實(shí)際生產(chǎn)環(huán)境請(qǐng)使用真實(shí)數(shù)據(jù)庫(kù)備份工具 tar -czf $BACKUP_DIR/db_$DATE.tar.gz /var/lib/mysql find $BACKUP_DIR -type f -mtime 7 -delete echo [$(date)] backup completed: $BACKUP_DIR/db_$DATE.tar.gz EOF然后設(shè)置屬主和權(quán)限sudo chown root:root /opt/scripts/db_backup.sh sudo chmod 750 /opt/scripts/db_backup.sh到這一步普通用戶 ops 即使能看到腳本也無(wú)法編輯它。5.3 創(chuàng)建普通用戶并配置 sudo 規(guī)則創(chuàng)建用戶 ops并加入需要的輔助組比如 ops 可能需要讀取某些日志但這不是必須的sudo useradd -m ops sudo passwd ops然后創(chuàng)建獨(dú)立的 sudoers 配置文件sudo visudo -f /etc/sudoers.d/ops-backup在打開(kāi)的編輯器里寫(xiě)入ops ALL(root) /opt/scripts/db_backup.sh注意我這里沒(méi)有加 NOPASSWD意思是執(zhí)行時(shí)需要輸入 ops 自己的密碼。寫(xiě)入后保存。驗(yàn)證語(yǔ)法sudo visudo -c如果輸出parsed OK就說(shuō)明配置沒(méi)問(wèn)題。5.4 普通用戶實(shí)際操作驗(yàn)證切換到 ops 用戶進(jìn)行驗(yàn)證sudo -u ops -i sudo /opt/scripts/db_backup.sh第一次會(huì)提示輸入 ops 的密碼輸入后腳本執(zhí)行。如果希望驗(yàn)證腳本內(nèi)部命令是否還需要額外授權(quán)可以在腳本里直接寫(xiě)一個(gè)需要 root 權(quán)限的操作比如touch /root/test_backup_marker然后在腳本中執(zhí)行。當(dāng)普通用戶運(yùn)行 sudo 腳本時(shí)腳本內(nèi)部已經(jīng)是 root 身份所以這個(gè) touch 也能成功。這就是 sudo 包裝腳本的特權(quán)傳播特性。如果要查看執(zhí)行記錄可以查看sudo tail -f /var/log/auth.log或者在使用 journald 的系統(tǒng)上journalctl -u sudo -f你會(huì)看到類似ops : TTYpts/0 ; PWD/home/ops ; USERroot ; COMMAND/opt/scripts/db_backup.sh的記錄。提示如果腳本里有一些命令不在默認(rèn) PATH 中一定要在腳本開(kāi)頭export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin避免 sudo 環(huán)境下找不到命令。5.5 權(quán)限收緊如何避免 ops 看到敏感文件有些腳本內(nèi)容本身會(huì)包含數(shù)據(jù)庫(kù)密碼普通用戶一旦可讀就等于泄露。更安全的做法是將腳本設(shè)為僅 root 可讀可執(zhí)行sudo chmod 700 /opt/scripts/db_backup.sh但這樣的話普通用戶還能執(zhí)行嗎答案是可以因?yàn)?sudo 是以 root 身份執(zhí)行這個(gè)腳本的。sudo 在執(zhí)行命令前不要求執(zhí)行者對(duì)腳本有讀取權(quán)限因?yàn)閳?zhí)行者是 rootroot 能讀取一切文件。所以如果普通用戶根本不需要了解腳本內(nèi)容設(shè)置700是最佳選擇。這樣即使有人查看腳本內(nèi)容也看不到敏感數(shù)據(jù)。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這部分是我真正在日常運(yùn)維中驗(yàn)證過(guò)的內(nèi)容很多坑如果不踩一遍光看文檔是發(fā)現(xiàn)不了的。6.1 用戶執(zhí)行時(shí)報(bào)錯(cuò)“對(duì)不起用戶 xxxx 無(wú)權(quán)以 root 的身份執(zhí)行”這個(gè)報(bào)錯(cuò)最常見(jiàn)的原因是 sudoers 規(guī)則沒(méi)匹配上。檢查幾個(gè)地方用戶名是否正確。命令路徑是否完全絕對(duì)路徑。是否存在其他更早的 sudoers 規(guī)則覆蓋。是否在/etc/sudoers.d/下創(chuàng)建了文件但文件權(quán)限不對(duì)。sudoers.d 下的文件必須屬主 root權(quán)限440否則 sudo 會(huì)直接忽略并在日志里提示權(quán)限不正確。修復(fù)方式sudo chown root:root /etc/sudoers.d/ops-backup sudo chmod 440 /etc/sudoers.d/ops-backup sudo visudo -c6.2 腳本本身能直接執(zhí)行但 sudo 執(zhí)行時(shí)報(bào)“找不到命令”這是因?yàn)?sudo 有secure_path默認(rèn)可能不含/usr/local/bin或/opt/scripts。兩個(gè)解決方案方案一腳本內(nèi)寫(xiě)全絕對(duì)路徑。比如把tar寫(xiě)成/bin/tar。方案二修改 sudoers 的 secure_path。比如在/etc/sudoers里增加Defaults secure_path/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/scripts我更推薦方案一因?yàn)檫@樣腳本不依賴 sudo 環(huán)境變量可移植性更好。6.3 sudo 執(zhí)行腳本不生效狀態(tài)碼 126 或 127126 通常表示腳本文件沒(méi)有執(zhí)行權(quán)限。即使 root 能讀但內(nèi)核要執(zhí)行一個(gè)腳本解釋器必須能找到。檢查chmod x。127 通常表示解釋器不存在比如腳本第一行寫(xiě)了#!/usr/bin/python3但系統(tǒng)里沒(méi)有 python3。用head -1 script.sh檢查。6.4 普通用戶執(zhí)行 sudo 腳本時(shí)腳本內(nèi)部又調(diào)用 sudo 導(dǎo)致死循環(huán)像我前面寫(xiě)的腳本如果腳本內(nèi)部有sudo systemctl reload nginx而腳本本身已經(jīng)是用 root 身份運(yùn)行的那么就會(huì)變成“root 用戶再 sudo 到 root”有時(shí)候會(huì)觸發(fā) sudo 的惡意命令拒絕策略。解決辦法很簡(jiǎn)單腳本內(nèi)部不要再寫(xiě) sudo因?yàn)檎麄€(gè)腳本已經(jīng)運(yùn)行在 root shell 下。直接寫(xiě)systemctl reload nginx即可。6.5 怎么臨時(shí)給某用戶一次性授權(quán)如果只是讓某用戶執(zhí)行一次特定命令可以在 sudoers 中臨時(shí)加一條帶時(shí)間限制的規(guī)則但 sudo 本身沒(méi)有“過(guò)期時(shí)間”功能。更實(shí)用的做法是使用運(yùn)維平臺(tái)的臨時(shí)授權(quán)接口或者簡(jiǎn)單粗暴地在用戶執(zhí)行完命令后馬上刪除 sudoers 文件。我個(gè)人的習(xí)慣是給 sudoers 文件按用途命名并備注日期。比如ops-temporary-backup-20250101執(zhí)行完畢后立即刪除sudo rm /etc/sudoers.d/ops-temporary-backup-20250101這樣即使有審計(jì)也能清楚看到什么時(shí)間段開(kāi)了什么權(quán)限。6.6 檢查當(dāng)前用戶實(shí)際擁有哪些 sudo 權(quán)限作為運(yùn)維人員我經(jīng)常需要快速確認(rèn)某個(gè)賬號(hào)到底能執(zhí)行什么。方法很簡(jiǎn)單sudo -l -U ops這會(huì)列出所有和 ops 相關(guān)的 sudo 規(guī)則。如果輸出太多可以針對(duì)用戶看sudo -lU ops這個(gè)命令在排查“為什么用戶能執(zhí)行某條命令”時(shí)非常有用能直接看到最終生效的規(guī)則是哪一條。7. 安全加固別讓授權(quán)變成后門(mén)最后再聊幾個(gè)我踩過(guò)的安全細(xì)節(jié)這些很容易被忽略但影響非常大。7.1 小心 sudo 包裝腳本里的“環(huán)境變量注入”腳本如果使用了用戶可控的環(huán)境變量比如$PATH、$LD_PRELOAD、$PYTHONPATH就可能被利用。舉個(gè)最簡(jiǎn)單的例子某腳本執(zhí)行tar但通過(guò)環(huán)境變量把tar指向惡意程序。解決方法是在腳本開(kāi)頭重置環(huán)境變量或者至少在sudoers里設(shè)置Defaults env_reset大多數(shù)發(fā)行版默認(rèn)已經(jīng)開(kāi)啟 env_reset但如果你自己改過(guò) sudoers就要確認(rèn)沒(méi)把它關(guān)掉。7.2 sudoers 規(guī)則順序越早匹配越優(yōu)先sudoers 規(guī)則是“先匹配先生效”。如果你有一個(gè)寬規(guī)則寫(xiě)在前面后面再寫(xiě)細(xì)規(guī)則也白搭。所以我的建議是顯式的精確規(guī)則永遠(yuǎn)寫(xiě)在最前面兜底規(guī)則寫(xiě)在最后。比如避免寫(xiě)這樣的寬規(guī)則ops ALL(root) NOPASSWD: /usr/bin/*這種規(guī)則等于開(kāi)放了整個(gè)/usr/bin下所有命令危害極大。如果你確實(shí)需要通配也要縮小到具體目錄和具體不可繞過(guò)的二進(jìn)制。7.3 審計(jì)提醒定期檢查 sudo 日志我習(xí)慣每周花五分鐘快速掃一下 auth.log 里的 sudo 記錄重點(diǎn)看有沒(méi)有異常頻率的提權(quán)操作。如果發(fā)現(xiàn)某賬號(hào)在凌晨頻繁執(zhí)行 sudo即使規(guī)則看起來(lái)沒(méi)問(wèn)題也要排查是不是賬號(hào)被濫用。日志查看方法sudo grep sudo /var/log/auth.log | tail -100在 journald 系統(tǒng)上journalctl _COMMsudo --since 7 days ago如果不想手動(dòng)看也可以簡(jiǎn)單寫(xiě)個(gè) cron 任務(wù)把 sudo 日志匯總發(fā)到運(yùn)維群。但這塊屬于擴(kuò)展內(nèi)容今天先不展開(kāi)。8. 最后的個(gè)人經(jīng)驗(yàn)如果你問(wèn)我這幾年在權(quán)限管理上最大的體會(huì)我覺(jué)得就一句話權(quán)限最小化絕不是一句口號(hào)而是每一次配置都要落到具體路徑、具體參數(shù)、具體用戶上。sudo 本身很強(qiáng)大強(qiáng)大到可以一句話就讓你擁有整個(gè)系統(tǒng)的權(quán)限也可以強(qiáng)大到只讓你執(zhí)行一個(gè)嚴(yán)格校驗(yàn)過(guò)的備份腳本。差別就在于你愿不愿意花那幾分鐘去寫(xiě)清楚規(guī)則。另外還有一個(gè)容易被忽視的點(diǎn)腳本的可維護(hù)性和權(quán)限管理同樣重要。我見(jiàn)過(guò)太多團(tuán)隊(duì)花大力氣把 sudo 規(guī)則寫(xiě)得滴水不漏但提權(quán)腳本本身寫(xiě)得一塌糊涂命令到處用相對(duì)路徑變量不校驗(yàn)出了問(wèn)題沒(méi)人敢改。久而久之這些“安全”的規(guī)則就變成了定時(shí)炸彈。所以我的建議是提權(quán)腳本要像生產(chǎn)代碼一樣對(duì)待版本管理、代碼評(píng)審、權(quán)限控制一個(gè)都不能少。這樣配合 sudo 精確規(guī)則才能形成一個(gè)真正可靠的權(quán)限體系。如果你現(xiàn)在正好有一個(gè)“普通用戶執(zhí)行 root 腳本”的需求我建議你從最小場(chǎng)景開(kāi)始先選一臺(tái)測(cè)試機(jī)寫(xiě)一個(gè)簡(jiǎn)單的腳本按我上面的步驟配置 sudoers然后用sudo -l -U 用戶名驗(yàn)證授權(quán)范圍再實(shí)際操作一遍。等你把這套流程跑通了再往生產(chǎn)環(huán)境推廣。這個(gè)順序能幫你避開(kāi)絕大多數(shù)低級(jí)事故。希望這篇文章能讓你少踩幾個(gè)坑。如果后續(xù)有機(jī)會(huì)我還會(huì)繼續(xù)分享關(guān)于 Linux 權(quán)限控制、自動(dòng)化運(yùn)維腳本設(shè)計(jì)、以及安全審計(jì)方面的一些實(shí)戰(zhàn)心得。