一、概述
1.1 背景介紹
說(shuō)實(shí)話,Linux 權(quán)限這塊我踩過(guò)不少坑。記得剛?cè)胄心菚?huì)兒,有次為了圖省事直接chmod 777 -R /var/www,結(jié)果被老大罵了一頓——"你這是把大門(mén)敞開(kāi)讓小偷隨便進(jìn)?。?
Linux 的權(quán)限體系是整個(gè)系統(tǒng)安全的基石。從最基礎(chǔ)的 rwx 三權(quán)分立,到 SUID/SGID 這些"特權(quán)通道",再到 ACL 細(xì)粒度控制,最后是 SELinux/AppArmor 這種強(qiáng)制訪問(wèn)控制,形成了一套層層遞進(jìn)的安全防護(hù)網(wǎng)。
2026 年了,隨著容器化和云原生的普及,權(quán)限管理變得更加復(fù)雜。你不僅要管好宿主機(jī)的權(quán)限,還得搞清楚容器內(nèi)的 UID 映射、Rootless 容器這些新玩意兒。這篇文章就把這些年我在生產(chǎn)環(huán)境中積累的經(jīng)驗(yàn)都掏出來(lái),希望能幫你少走彎路。
1.2 技術(shù)特點(diǎn)
層次分明:基礎(chǔ)權(quán)限 → 特殊權(quán)限 → ACL → MAC,由簡(jiǎn)到繁
向后兼容:新特性不影響老系統(tǒng),平滑升級(jí)
靈活可控:從粗粒度到細(xì)粒度,滿足各種場(chǎng)景需求
審計(jì)友好:所有權(quán)限變更都可追溯,便于合規(guī)審計(jì)
1.3 適用場(chǎng)景
Web 服務(wù)器:Nginx/Apache 的目錄權(quán)限配置
多用戶(hù)開(kāi)發(fā)環(huán)境:團(tuán)隊(duì)協(xié)作時(shí)的代碼目錄權(quán)限管理
容器化部署:Docker/Kubernetes 中的權(quán)限映射
合規(guī)審計(jì):滿足等保、SOC2 等安全合規(guī)要求
數(shù)據(jù)安全:敏感文件的訪問(wèn)控制
1.4 環(huán)境要求
| 組件 | 版本要求 | 說(shuō)明 |
|---|---|---|
| 操作系統(tǒng) | CentOS 8+/Ubuntu 20.04+/Debian 11+ | 推薦使用最新 LTS 版本 |
| 內(nèi)核版本 | 5.4+ | 支持完整的 ACL 和 capabilities |
| 文件系統(tǒng) | ext4/xfs/btrfs | 需支持?jǐn)U展屬性(xattr) |
| SELinux | 3.0+ | CentOS/RHEL 默認(rèn)啟用 |
| AppArmor | 3.0+ | Ubuntu/Debian 默認(rèn)啟用 |
二、詳細(xì)步驟
2.1 準(zhǔn)備工作
2.1.1 系統(tǒng)檢查
# 檢查系統(tǒng)版本 cat /etc/os-release # 檢查內(nèi)核版本(需要 5.4+ 以獲得完整特性支持) uname -r # 檢查文件系統(tǒng)類(lèi)型 df -Th # 檢查是否支持 ACL grep -i acl /boot/config-$(uname -r) 2>/dev/null || zcat /proc/config.gz 2>/dev/null | grep -i acl # 檢查 SELinux 狀態(tài)(RHEL 系) getenforce 2>/dev/null ||echo"SELinux not installed" # 檢查 AppArmor 狀態(tài)(Debian 系) aa-status 2>/dev/null ||echo"AppArmor not installed"
2.1.2 安裝必要工具
# RHEL/CentOS 系列 sudo dnf install -y acl attr policycoreutils-python-utils setools-console # Debian/Ubuntu 系列 sudo apt update sudo apt install -y acl attr apparmor-utils auditd
2.2 核心配置
2.2.1 基礎(chǔ)權(quán)限:rwx 三劍客
先來(lái)復(fù)習(xí)一下基礎(chǔ),這塊很多人以為自己懂了,其實(shí)細(xì)節(jié)上還是會(huì)犯錯(cuò)。
# 權(quán)限的數(shù)字表示法 # r=4, w=2, x=1 # 755 = rwxr-xr-x = 所有者全權(quán)限,組和其他人只讀+執(zhí)行 # 查看文件權(quán)限的詳細(xì)信息 ls -la /etc/passwd # -rw-r--r-- 1 root root 2847 Jan 15 10:23 /etc/passwd # │├─┤├─┤├─┤ # │ │ │ └── 其他用戶(hù)權(quán)限 (r--) # │ │ └───── 所屬組權(quán)限 (r--) # │ └──────── 所有者權(quán)限 (rw-) # └────────── 文件類(lèi)型 (-=普通文件, d=目錄, l=鏈接) # 修改權(quán)限的兩種方式 # 方式一:數(shù)字法(推薦,精確控制) chmod 644 config.yml # rw-r--r-- chmod 755 script.sh # rwxr-xr-x chmod 600 .ssh/id_rsa # rw------- (私鑰必須是600!) # 方式二:符號(hào)法(適合微調(diào)) chmod u+x script.sh # 給所有者加執(zhí)行權(quán)限 chmod g-w config.yml # 去掉組的寫(xiě)權(quán)限 chmod o= secret.txt # 清空其他用戶(hù)的所有權(quán)限 chmod a+r public.html # 所有人加讀權(quán)限
我踩過(guò)的坑:有次部署應(yīng)用,死活啟動(dòng)不了,查了半天發(fā)現(xiàn)是配置文件權(quán)限給成了000。所以現(xiàn)在我養(yǎng)成習(xí)慣,部署腳本里一定會(huì)加權(quán)限檢查。
2.2.2 目錄權(quán)限的特殊之處
目錄的權(quán)限和文件不太一樣,這點(diǎn)很多新手會(huì)搞混:
# 目錄權(quán)限含義: # r - 可以列出目錄內(nèi)容(ls) # w - 可以在目錄中創(chuàng)建/刪除文件 # x - 可以進(jìn)入目錄(cd)和訪問(wèn)目錄中的文件 # 實(shí)驗(yàn):創(chuàng)建測(cè)試目錄 mkdir -p /tmp/perm_test &&cd/tmp/perm_test # 場(chǎng)景1:只有 r 沒(méi)有 x mkdir test_r && chmod 444 test_r echo"hello"> test_r/file.txt 2>/dev/null # 會(huì)失敗 ls test_r/ # 能看到文件名,但看不到詳情 cat test_r/file.txt # 失敗,因?yàn)闆](méi)有 x 權(quán)限 # 場(chǎng)景2:只有 x 沒(méi)有 r mkdir test_x && chmod 111 test_x echo"hello"> test_x/file.txt ls test_x/ # 失敗,不能列目錄 cat test_x/file.txt # 成功!知道文件名就能訪問(wèn) # 場(chǎng)景3:生產(chǎn)環(huán)境常用配置 chmod 755 /var/www/html # Web 目錄,所有人可讀可進(jìn)入 chmod 750 /app/config # 配置目錄,組內(nèi)可讀,其他人禁止 chmod 700 /root/.ssh # SSH 目錄,僅所有者可訪問(wèn)
2.2.3 特殊權(quán)限:SUID、SGID、Sticky Bit
這三個(gè)特殊權(quán)限是很多安全問(wèn)題的根源,但用好了也是利器:
# SUID (Set User ID) - 數(shù)字表示:4xxx # 執(zhí)行文件時(shí),臨時(shí)獲得文件所有者的權(quán)限 # 典型例子:passwd 命令需要修改 /etc/shadow,普通用戶(hù)執(zhí)行時(shí)臨時(shí)獲得 root 權(quán)限 ls -la /usr/bin/passwd # -rwsr-xr-x 1 root root 68208 Mar 14 2023 /usr/bin/passwd # ^-- 注意這個(gè) s,表示設(shè)置了 SUID # 設(shè)置 SUID chmod u+s /usr/local/bin/myapp chmod 4755 /usr/local/bin/myapp # SGID (Set Group ID) - 數(shù)字表示:2xxx # 對(duì)文件:執(zhí)行時(shí)臨時(shí)獲得文件所屬組的權(quán)限 # 對(duì)目錄:在該目錄下創(chuàng)建的文件自動(dòng)繼承目錄的所屬組(團(tuán)隊(duì)協(xié)作神器?。? # 團(tuán)隊(duì)共享目錄配置 mkdir -p /data/team_project chown root:developers /data/team_project chmod 2775 /data/team_project # 現(xiàn)在 developers 組的成員在這里創(chuàng)建的文件,所屬組都是 developers # Sticky Bit - 數(shù)字表示:1xxx # 只對(duì)目錄有效:目錄中的文件只能被文件所有者或 root 刪除 # 典型例子:/tmp 目錄 ls -ld /tmp # drwxrwxrwt 15 root root 4096 Jan 20 10:00 /tmp # ^-- 注意這個(gè) t,表示設(shè)置了 Sticky Bit # 設(shè)置 Sticky Bit chmod +t /data/shared chmod 1777 /data/shared
安全警告:SUID 是安全審計(jì)的重點(diǎn)關(guān)注對(duì)象。定期檢查系統(tǒng)中的 SUID 文件:
# 查找所有 SUID 文件 find / -perm -4000 -typef 2>/dev/null # 查找所有 SGID 文件 find / -perm -2000 -typef 2>/dev/null # 生產(chǎn)環(huán)境建議:建立基線,定期對(duì)比 find / -perm -4000 -typef 2>/dev/null | sort > /var/log/suid_baseline_$(date +%Y%m%d).txt
2.2.4 文件所有權(quán):chown 和 chgrp
# 修改所有者
chown nginx /var/www/html/index.html
# 修改所有者和所屬組
chown nginx:www-data /var/www/html/index.html
# 只修改所屬組
chgrp www-data /var/www/html/index.html
# 或者
chown :www-data /var/www/html/index.html
# 遞歸修改(謹(jǐn)慎使用?。?chown -R nginx:www-data /var/www/html/
# 只修改符合條件的文件(更安全的做法)
find /var/www/html -typef -execchown nginx:www-data {} ;
find /var/www/html -typed -execchown nginx:www-data {} ;
# 參考符號(hào)鏈接的目標(biāo)(默認(rèn)不跟隨)
chown -h nginx:www-data /var/www/html/link # 修改鏈接本身
chown nginx:www-data /var/www/html/link # 修改鏈接指向的文件
2.2.5 ACL:細(xì)粒度權(quán)限控制
傳統(tǒng)的 rwx 權(quán)限有個(gè)致命缺陷:只能設(shè)置一個(gè)所有者和一個(gè)所屬組。如果你想讓用戶(hù) A 有讀寫(xiě)權(quán)限,用戶(hù) B 只有讀權(quán)限,用戶(hù) C 完全沒(méi)權(quán)限,傳統(tǒng)權(quán)限就搞不定了。這時(shí)候 ACL 就派上用場(chǎng)了。
# 查看文件的 ACL getfacl /data/project/config.yml # 輸出示例: # file: data/project/config.yml # owner: root # group: developers # user::rw- # userrw- # alice 用戶(hù)有讀寫(xiě)權(quán)限 # userr-- # bob 用戶(hù)只有讀權(quán)限 # group::r-- # grouprw- # ops 組有讀寫(xiě)權(quán)限 # mask::rw- # other::--- # 設(shè)置用戶(hù) ACL setfacl -m urw /data/project/config.yml # 給 alice 讀寫(xiě)權(quán)限 setfacl -m ur /data/project/config.yml # 給 bob 只讀權(quán)限 # 設(shè)置組 ACL setfacl -m grw /data/project/config.yml # 給 ops 組讀寫(xiě)權(quán)限 # 刪除特定 ACL setfacl -x u:alice /data/project/config.yml # 刪除 alice 的 ACL setfacl -x g:ops /data/project/config.yml # 刪除 ops 組的 ACL # 刪除所有 ACL(恢復(fù)到傳統(tǒng)權(quán)限) setfacl -b /data/project/config.yml # 遞歸設(shè)置 ACL setfacl -R -m urwX /data/project/ # X 表示僅對(duì)目錄設(shè)置執(zhí)行權(quán)限 # 設(shè)置默認(rèn) ACL(新創(chuàng)建的文件自動(dòng)繼承) setfacl -d -m urw /data/project/ # 目錄下新文件自動(dòng)給 alice 讀寫(xiě)權(quán)限 setfacl -d -m grwx /data/project/ # 目錄下新文件自動(dòng)給 developers 組全權(quán)限
ACL 的 mask 機(jī)制:這是個(gè)容易被忽略但很重要的概念。mask 定義了 ACL 權(quán)限的上限。
# 查看當(dāng)前 mask getfacl /data/project/config.yml | grep mask # 設(shè)置 mask(限制所有 ACL 的最大權(quán)限) setfacl -m m::r /data/project/config.yml # 即使 alice 設(shè)置了 rw 權(quán)限,實(shí)際生效的也只有 r(被 mask 限制) # 注意:chmod 會(huì)影響 mask! chmod 640 /data/project/config.yml # 這會(huì)把 mask 設(shè)置為 r--,可能導(dǎo)致 ACL 權(quán)限失效
我的經(jīng)驗(yàn):ACL 雖然強(qiáng)大,但也增加了復(fù)雜度。我的建議是:
能用組權(quán)限解決的,就不要用 ACL
用了 ACL 一定要做好文檔記錄
定期審計(jì) ACL 配置,避免權(quán)限膨脹
2.3 啟動(dòng)和驗(yàn)證
2.3.1 權(quán)限配置驗(yàn)證腳本
#!/bin/bash
# 文件名:check_permissions.sh
# 用途:驗(yàn)證關(guān)鍵目錄和文件的權(quán)限配置
RED='?33[0;31m'
GREEN='?33[0;32m'
YELLOW='?33[1;33m'
NC='?33[0m'
check_permission() {
localpath=$1
localexpected_perm=$2
localexpected_owner=$3
localexpected_group=$4
if[[ ! -e"$path"]];then
echo-e"${RED}[FAIL]${NC}$pathdoes not exist"
return1
fi
localactual_perm=$(stat-c"%a""$path")
localactual_owner=$(stat-c"%U""$path")
localactual_group=$(stat-c"%G""$path")
localstatus=0
if[["$actual_perm"!="$expected_perm"]];then
echo-e"${RED}[FAIL]${NC}$pathpermission: expected$expected_perm, got$actual_perm"
status=1
fi
if[["$actual_owner"!="$expected_owner"]];then
echo-e"${RED}[FAIL]${NC}$pathowner: expected$expected_owner, got$actual_owner"
status=1
fi
if[["$actual_group"!="$expected_group"]];then
echo-e"${YELLOW}[WARN]${NC}$pathgroup: expected$expected_group, got$actual_group"
fi
if[[$status-eq 0 ]];then
echo-e"${GREEN}[OK]${NC}$path"
fi
return$status
}
echo"=== Permission Check Report ==="
echo"Date:$(date)"
echo""
# 檢查關(guān)鍵系統(tǒng)文件
echo"--- System Files ---"
check_permission"/etc/passwd""644""root""root"
check_permission"/etc/shadow""640""root""shadow"
check_permission"/etc/ssh/sshd_config""600""root""root"
# 檢查 SSH 目錄
echo""
echo"--- SSH Directory ---"
check_permission"$HOME/.ssh""700""$USER""$USER"
check_permission"$HOME/.ssh/authorized_keys""600""$USER""$USER"2>/dev/null
check_permission"$HOME/.ssh/id_rsa""600""$USER""$USER"2>/dev/null
# 檢查 Web 目錄(如果存在)
if[[ -d"/var/www/html"]];then
echo""
echo"--- Web Directory ---"
check_permission"/var/www/html""755""www-data""www-data"
fi
echo""
echo"=== Check Complete ==="
2.3.2 SUID/SGID 審計(jì)
#!/bin/bash # 文件名:audit_suid.sh # 用途:審計(jì)系統(tǒng)中的 SUID/SGID 文件 BASELINE_FILE="/var/log/suid_baseline.txt" CURRENT_FILE="/tmp/suid_current_$(date +%Y%m%d).txt" # 生成當(dāng)前 SUID 文件列表 find / -typef ( -perm -4000 -o -perm -2000 ) 2>/dev/null | sort >"$CURRENT_FILE" if[[ -f"$BASELINE_FILE"]];then echo"=== SUID/SGID File Changes ===" echo"" # 新增的 SUID 文件 new_files=$(comm -13"$BASELINE_FILE""$CURRENT_FILE") if[[ -n"$new_files"]];then echo"!!! NEW SUID/SGID FILES DETECTED !!!" echo"$new_files" echo"" fi # 刪除的 SUID 文件 removed_files=$(comm -23"$BASELINE_FILE""$CURRENT_FILE") if[[ -n"$removed_files"]];then echo"--- Removed SUID/SGID files ---" echo"$removed_files" echo"" fi if[[ -z"$new_files"&& -z"$removed_files"]];then echo"No changes detected since last baseline." fi else echo"No baseline file found. Creating baseline..." cp"$CURRENT_FILE""$BASELINE_FILE" echo"Baseline created at$BASELINE_FILE" echo"" echo"Current SUID/SGID files:" cat"$CURRENT_FILE" fi
三、示例代碼和配置
3.1 完整配置示例
3.1.1 SELinux 配置(RHEL/CentOS 系)
SELinux 是強(qiáng)制訪問(wèn)控制(MAC)的實(shí)現(xiàn),比傳統(tǒng)權(quán)限更加嚴(yán)格。很多人遇到問(wèn)題就直接setenforce 0關(guān)掉,這是非常不好的習(xí)慣。
# 查看 SELinux 狀態(tài) getenforce # Enforcing = 強(qiáng)制模式(生產(chǎn)環(huán)境推薦) # Permissive = 寬容模式(只記錄不阻止,調(diào)試用) # Disabled = 禁用 sestatus # 查看詳細(xì)狀態(tài) # 臨時(shí)切換模式(重啟后失效) sudo setenforce 0 # 切換到 Permissive sudo setenforce 1 # 切換到 Enforcing # 永久修改(需要重啟) sudo vim /etc/selinux/config # SELINUX=enforcing # 查看文件的 SELinux 上下文 ls -Z /var/www/html/ # -rw-r--r--. root root unconfined_uhttpd_sys_content_t:s0 index.html # └─────────────────────────────────────────┘ # SELinux 上下文 # 修改文件的 SELinux 上下文 # 臨時(shí)修改(重新標(biāo)記后會(huì)恢復(fù)) chcon -t httpd_sys_content_t /var/www/html/newfile.html # 永久修改(推薦) semanage fcontext -a -t httpd_sys_content_t"/data/web(/.*)?" restorecon -Rv /data/web/ # 查看 SELinux 布爾值 getsebool -a | grep httpd # 設(shè)置布爾值(允許 httpd 連接網(wǎng)絡(luò)) setsebool -P httpd_can_network_connect on
SELinux 故障排查:
# 查看 SELinux 拒絕日志 sudo ausearch -m avc -ts recent # 使用 audit2why 分析原因 sudo ausearch -m avc -ts recent | audit2why # 生成允許規(guī)則(謹(jǐn)慎使用?。?sudo ausearch -m avc -ts recent | audit2allow -M mypolicy sudo semodule -i mypolicy.pp # 實(shí)用技巧:臨時(shí)切換到 Permissive 模式測(cè)試 sudo setenforce 0 # 測(cè)試功能是否正常 # 如果正常,說(shuō)明是 SELinux 問(wèn)題 sudo setenforce 1 # 然后根據(jù)日志修復(fù) SELinux 配置
3.1.2 AppArmor 配置(Ubuntu/Debian 系)
# 查看 AppArmor 狀態(tài) sudo aa-status # 查看特定程序的配置文件 cat /etc/apparmor.d/usr.sbin.nginx # AppArmor 模式 # enforce - 強(qiáng)制模式 # complain - 投訴模式(只記錄不阻止) # disabled - 禁用 # 切換到投訴模式(調(diào)試用) sudo aa-complain /usr/sbin/nginx # 切換到強(qiáng)制模式 sudo aa-enforce /usr/sbin/nginx # 禁用特定配置 sudo aa-disable /usr/sbin/nginx # 重新加載配置 sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx # 查看日志 sudo dmesg | grep apparmor sudo journalctl -k | grep apparmor
自定義 AppArmor 配置示例:
# /etc/apparmor.d/usr.local.bin.myapp #include/usr/local/bin/myapp { #include #include # 可執(zhí)行文件 /usr/local/bin/myapp mr, # 配置文件(只讀) /etc/myapp/** r, # 數(shù)據(jù)目錄(讀寫(xiě)) /var/lib/myapp/** rw, # 日志目錄 /var/log/myapp/** w, # 臨時(shí)文件 /tmp/myapp-* rw, # 網(wǎng)絡(luò)訪問(wèn) network inet stream, network inet dgram, # 拒絕其他所有訪問(wèn) deny /etc/shadow r, deny /etc/passwd w, }
3.2 實(shí)際應(yīng)用案例
案例一:容器環(huán)境權(quán)限管理
2026 年了,不懂容器權(quán)限基本沒(méi)法干活。這塊坑特別多,我來(lái)詳細(xì)說(shuō)說(shuō)。
# Docker 默認(rèn)以 root 運(yùn)行,這是個(gè)安全隱患 docker run -it ubuntu whoami # root # 指定用戶(hù)運(yùn)行(推薦) docker run -it --user 1000:1000 ubuntu whoami # 會(huì)顯示 uid=1000 # 在 Dockerfile 中指定用戶(hù) # Dockerfile 示例 cat <'EOF'?> Dockerfile FROM ubuntu:22.04 # 創(chuàng)建非 root 用戶(hù) RUN groupadd -r appgroup && useradd -r -g appgroup appuser # 設(shè)置工作目錄權(quán)限 WORKDIR /app COPY --chown=appuser:appgroup . . # 切換到非 root 用戶(hù) USER appuser CMD ["./myapp"] EOF
UID 映射問(wèn)題:容器內(nèi)的 UID 和宿主機(jī)是共享的!
# 容器內(nèi) UID 1000 = 宿主機(jī) UID 1000 # 這可能導(dǎo)致權(quán)限問(wèn)題 # 查看容器內(nèi)進(jìn)程的實(shí)際 UID docker run -d --nametestnginx ps aux | grep nginx # 你會(huì)看到宿主機(jī)上顯示的是 UID,不是用戶(hù)名 # 解決方案:使用 User Namespace(Rootless 容器) # Docker Rootless 模式 dockerd-rootless-setuptool.sh install # 驗(yàn)證 Rootless 模式 docker info | grep -i rootless
Kubernetes 中的權(quán)限控制:
# Pod Security Context 示例 apiVersion:v1 kind:Pod metadata: name:secure-pod spec: securityContext: runAsNonRoot:true runAsUser:1000 runAsGroup:1000 fsGroup:1000 containers: -name:app image:myapp:latest securityContext: allowPrivilegeEscalation:false readOnlyRootFilesystem:true capabilities: drop: -ALL add: -NET_BIND_SERVICE# 只添加必要的 capability
案例二:Web 服務(wù)器權(quán)限配置最佳實(shí)踐
#!/bin/bash
# 文件名:setup_web_permissions.sh
# 用途:配置 Nginx Web 服務(wù)器的權(quán)限
WEB_ROOT="/var/www/html"
WEB_USER="www-data"
WEB_GROUP="www-data"
UPLOAD_DIR="${WEB_ROOT}/uploads"
# 創(chuàng)建目錄結(jié)構(gòu)
mkdir -p"${WEB_ROOT}"/{static,uploads,logs}
# 設(shè)置所有權(quán)
chown -R${WEB_USER}:${WEB_GROUP}${WEB_ROOT}
# 設(shè)置目錄權(quán)限
find${WEB_ROOT}-typed -execchmod 755 {} ;
# 設(shè)置文件權(quán)限
find${WEB_ROOT}-typef -execchmod 644 {} ;
# 上傳目錄特殊處理(需要寫(xiě)權(quán)限,但禁止執(zhí)行)
chmod 775${UPLOAD_DIR}
# 在 Nginx 配置中禁止執(zhí)行上傳目錄的腳本
# location /uploads/ {
# location ~ .(php|pl|py|sh)$ { deny all; }
# }
# 配置文件權(quán)限(敏感信息)
chmod 640 /etc/nginx/conf.d/*.conf
chown root:${WEB_GROUP}/etc/nginx/conf.d/*.conf
echo"Web permissions configured successfully!"
四、最佳實(shí)踐和注意事項(xiàng)
4.1 最佳實(shí)踐
4.1.1 最小權(quán)限原則
這是安全的黃金法則,說(shuō)起來(lái)簡(jiǎn)單做起來(lái)難。
# 錯(cuò)誤示范(千萬(wàn)別這么干!) chmod 777 /var/www/html # 全開(kāi)放,等著被黑吧 chmod -R 777 / # 系統(tǒng)直接廢了 # 正確做法:按需分配 # 1. 先確定誰(shuí)需要訪問(wèn) # 2. 確定需要什么權(quán)限(讀/寫(xiě)/執(zhí)行) # 3. 只給必要的權(quán)限 # 常用權(quán)限速查 # 644 - 普通文件(所有者讀寫(xiě),其他人只讀) # 755 - 可執(zhí)行文件/目錄(所有者全權(quán)限,其他人讀+執(zhí)行) # 600 - 敏感文件(僅所有者讀寫(xiě)) # 700 - 私有目錄(僅所有者訪問(wèn)) # 640 - 配置文件(所有者讀寫(xiě),組內(nèi)只讀) # 750 - 應(yīng)用目錄(所有者全權(quán)限,組內(nèi)讀+執(zhí)行)
4.1.2 安全加固清單
#!/bin/bash # 文件名:security_hardening.sh # 用途:系統(tǒng)權(quán)限安全加固 echo"=== Starting Security Hardening ===" # 1. 關(guān)鍵系統(tǒng)文件權(quán)限 chmod 644 /etc/passwd chmod 640 /etc/shadow chmod 644 /etc/group chmod 640 /etc/gshadow chmod 600 /etc/ssh/sshd_config chmod 700 /root # 2. 限制 cron 訪問(wèn) chmod 600 /etc/crontab chmod 700 /etc/cron.d chmod 700 /etc/cron.daily chmod 700 /etc/cron.hourly # 3. 設(shè)置 umask(新文件默認(rèn)權(quán)限) # 在 /etc/profile 或 /etc/bashrc 中設(shè)置 # umask 027 # 新文件 640,新目錄 750 # 4. 禁用不必要的 SUID # 根據(jù)實(shí)際需求決定是否移除 # chmod u-s /usr/bin/chage # chmod u-s /usr/bin/gpasswd echo"=== Security Hardening Complete ==="
4.2 注意事項(xiàng)
4.2.1 常見(jiàn)錯(cuò)誤
| 錯(cuò)誤現(xiàn)象 | 原因分析 | 解決方案 |
|---|---|---|
| Permission denied | 權(quán)限不足或 SELinux 阻止 | 檢查 rwx 權(quán)限和 SELinux 上下文 |
| Operation not permitted | 文件有 immutable 屬性 | lsattr 檢查,chattr -i移除 |
| chmod 不生效 | 文件系統(tǒng)掛載為只讀 | mount -o remount,rw |
| ACL 權(quán)限失效 | mask 限制或 chmod 覆蓋 | 檢查 mask 設(shè)置 |
4.2.2 危險(xiǎn)操作警告
# 這些命令可能導(dǎo)致系統(tǒng)崩潰,請(qǐng)三思! # 1. 遞歸修改根目錄權(quán)限 chmod -R 777 / # 絕對(duì)禁止! chown -R user:group / # 絕對(duì)禁止! # 2. 修改關(guān)鍵系統(tǒng)文件 chmod 777 /etc/shadow # 安全漏洞 chmod 777 /etc/sudoers # sudo 會(huì)拒絕工作 # 3. 移除自己的權(quán)限 chmod 000 ~/.bashrc # 可能無(wú)法登錄
五、故障排查和監(jiān)控
5.1 故障排查
5.1.1 權(quán)限問(wèn)題診斷流程
# 第一步:檢查基礎(chǔ)權(quán)限 ls -la /path/to/file stat/path/to/file # 第二步:檢查 ACL getfacl /path/to/file # 第三步:檢查擴(kuò)展屬性 lsattr /path/to/file # 第四步:檢查 SELinux(RHEL 系) ls -Z /path/to/file ausearch -m avc -ts recent # 第五步:檢查 AppArmor(Debian 系) aa-status dmesg | grep apparmor
5.2 性能監(jiān)控
5.2.1 權(quán)限審計(jì)配置
# 使用 auditd 監(jiān)控權(quán)限變更 # 安裝 auditd sudo apt install auditd # Debian/Ubuntu sudo dnf install audit # RHEL/CentOS # 添加審計(jì)規(guī)則 sudo auditctl -w /etc/passwd -p wa -k passwd_changes sudo auditctl -w /etc/shadow -p wa -k shadow_changes sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes # 查看審計(jì)日志 sudo ausearch -k passwd_changes
5.3 備份與恢復(fù)
# 備份文件權(quán)限 getfacl -R /data > /backup/data_acl_backup.txt # 恢復(fù)文件權(quán)限 setfacl --restore=/backup/data_acl_backup.txt
六、總結(jié)
6.1 技術(shù)要點(diǎn)回顧
基礎(chǔ)權(quán)限:rwx 三權(quán)分立,數(shù)字法和符號(hào)法靈活運(yùn)用
特殊權(quán)限:SUID/SGID/Sticky Bit 各有用途,謹(jǐn)慎使用
ACL:細(xì)粒度控制,注意 mask 機(jī)制
SELinux/AppArmor:強(qiáng)制訪問(wèn)控制,別輕易關(guān)閉
容器權(quán)限:UID 映射、Rootless 模式是趨勢(shì)
6.2 進(jìn)階學(xué)習(xí)方向
Linux Capabilities:比 SUID 更細(xì)粒度的特權(quán)控制
Seccomp:系統(tǒng)調(diào)用過(guò)濾,容器安全必備
eBPF 安全:新一代內(nèi)核級(jí)安全監(jiān)控
6.3 參考資料
Linux man pages - chmod/chown
Red Hat SELinux Guide
Ubuntu AppArmor Wiki
Docker Security Best Practices
作者寄語(yǔ):權(quán)限管理看似簡(jiǎn)單,實(shí)則博大精深。記住最小權(quán)限原則,養(yǎng)成良好習(xí)慣,你的系統(tǒng)會(huì)更加安全。有問(wèn)題歡迎交流!
-
Linux
+關(guān)注
關(guān)注
88文章
11797瀏覽量
219387 -
容器
+關(guān)注
關(guān)注
0文章
533瀏覽量
23012
原文標(biāo)題:Linux 權(quán)限體系詳解:chmod、chown 與 ACL 的進(jìn)階玩法
文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
嵌入式Linux入門(mén)(二、Linux文件系統(tǒng)、文件類(lèi)型及權(quán)限管理)
【Linux學(xué)習(xí)雜談】之文件權(quán)限管理
Linux 中文件權(quán)限管理的探討
Linux改變文件或目錄的訪問(wèn)權(quán)限命令
Windows下linux權(quán)限管理問(wèn)題解析
淺談Linux權(quán)限管理的ACL權(quán)限
linux文件訪問(wèn)權(quán)限怎么設(shè)置
Linux把目錄權(quán)限給指定用戶(hù)
Linux文件權(quán)限及Makefile
Linux用戶(hù)身份與進(jìn)程權(quán)限詳解
Linux文件權(quán)限詳解
搞懂Linux權(quán)限管理,提升系統(tǒng)安全性與穩(wěn)定性
linux權(quán)限管理詳解
Linux權(quán)限管理基礎(chǔ)入門(mén)
Linux文件權(quán)限管理詳解
評(píng)論