在現代Linux系統中，為Shell腳本設置 SUID（Set User ID） 權限位幾乎是無效的。這個看似簡單的現象背后，是Linux內核設計者們在安全與便利性之間做出的一個至關重要的歷史性抉擇。要徹底理解這一點，我們需要深入到內核層面，并追溯其演變過程。

1. 內核的執行模型：二進制與解釋腳本的根本區別

首先，我們需要區分Linux內核是如何處理可執行的二進制程序和解釋型腳本的。

• 二進制程序執行流程：

  1. 當你執行一個a.out這樣的二進制文件時，內核會直接啟動一個新的進程。
  2. 內核檢查文件的SUID權限位。
  3. 如果SUID位被設置，內核會主動且在進程啟動的第一時間將該進程的有效用戶ID (EUID) 設置為文件的所有者ID。
  4. 從這一刻起，這個進程就擁有了對應的高權限（例如root）。

• 解釋型腳本執行流程：

  1. 當你執行一個script.sh腳本時，內核并不會直接執行它。
  2. 內核會讀取文件的 “Shebang”行（#!）。
  3. 內核發現這是一個需要解釋器（如/bin/bash）來執行的腳本。
  4. 內核會以當前用戶的權限，啟動一個新的進程，這個進程的可執行文件是指定的解釋器（如/bin/bash）。
  5. SUID權限在這里被“截斷”了。 腳本的SUID權限是作用于文件本身的，但內核沒有將這個權限傳遞給新啟動的解釋器進程。
  6. 新啟動的/bin/bash進程以低權限運行，然后由它來讀取并執行腳本中的每一行命令。

這個本質區別是所有問題的根源：SUID權限的賦予是內核對可執行文件的特有操作，它不適用于間接執行的解釋器。

2. 歷史上的安全教訓：SUID腳本的巨大漏洞

在早期的UNIX系統（如System V）中，SUID腳本是被支持的。但很快，開發者們就發現了其中的巨大安全隱患。

• 環境中毒（Environment Poisoning）：

  • SUID腳本通常會依賴一些外部命令，例如grep、cat、rm等。
  • 這些命令的查找路徑由PATH環境變量決定。
  • 攻擊者可以創建一個名為grep的惡意程序，并將其所在的目錄添加到PATH環境變量的開頭。
  • 當SUID腳本以root權限執行時，它會優先找到并運行攻擊者的惡意grep程序，而不是系統原本的grep，從而獲得root權限。
  • 因為腳本本身無法控制或清理PATH變量，這種攻擊幾乎無法防御。

• 命令注入（Command Injection）：

  • 如果腳本需要處理用戶輸入，比如echo $1（其中$1是用戶輸入的第一個參數）。
  • 攻擊者可以構造惡意輸入，例如 Hello; rm -rf /。
  • 當腳本以SUID權限執行時，echo命令執行完后，分號后面的rm -rf /命令也會被解釋器以root權限執行，從而導致災難性的后果。

這些漏洞表明，腳本的開放性和動態性（依賴于解釋器和環境變量）使得SUID權限變得極其危險，因為腳本無法像編譯好的二進制程序那樣嚴格控制其執行環境。

3. 現代Linux的解決方案：放棄SUID腳本，走向更安全的權限管理

面對這些不可避免的漏洞，Linux社區最終達成了共識：為了系統的整體安全，必須從內核層面禁用SUID對解釋型腳本的支持。

這使得開發者必須采用更安全、更可控的方式來實現特權操作：

• 編譯型語言： 這是最推薦的做法。使用C/C++等編譯型語言編寫需要SUID權限的程序。編譯后的二進制文件不依賴外部解釋器，其行為更加可控，也更容易審計。sudo、passwd等核心系統工具都是用這種方式實現的。

• sudo機制： sudo是比SUID更現代、更強大的權限管理工具。

  • 它允許管理員精確配置哪些用戶可以以哪個身份執行哪些命令，甚至可以限制允許使用的參數。
  • 這提供了一種細粒度的授權方式，避免了SUID帶來的“全有或全無”的風險。

• setcap（Capability）： setcap是Linux內核提供的一種更精細的權限控制機制。

  • 它允許開發者將一個特權操作（如綁定到小于1024的端口）單獨授予某個二進制文件，而無需賦予它完整的root權限。
  • 這大大降低了程序的權限，即使被攻擊，也無法對系統造成更大的破壞。

總而言之，現代Linux發行版對Shell腳本的SUID位選擇性忽略，是內核為了系統安全而做出的主動且必要的設計。它強制開發者使用更安全、更可控的編譯型程序或現代化的sudo/setcap等工具來處理特權操作，從而從根本上杜絕了過去SUID腳本所帶來的各種難以防范的漏洞。