1. 程式人生 > >【安全】10分鐘理解Capability本質

【安全】10分鐘理解Capability本質

核心定理大公式
(注:man capabilities 7)
           P'(ambient)     = (file is privileged) ? 0 : P(ambient)
           P'(permitted)   = (P(inheritable) & F(inheritable)) |
                             (F(permitted) & cap_bset) | P'(ambient)
           P'(effective)   = F(effective) ? P'(permitted) : P'(ambient)
           P'(inheritable) = P(inheritable)    [i.e., unchanged]

       where:
           P         denotes the value of a thread capability set before the
                     
execve(2)
P' denotes the value of a thread capability set after the execve(2) F denotes a file capability set cap_bset is the value of the capability bounding set (described below).

Linux核心行為
1. exec後仍然是root程序,在計算最終程序cap時,把file的所有全部設定為1 2. inherent的不能超過bnd(邊界) 3. uid切換普通,p,e清空,b,i不變 4. euid切換普通,e清空,其餘不變,還是可以切回到root,因此p不清
根據公式,得出推論
1. root使用者如果把自己的3個全部搞為0,bnd不為0,exec之後全為1,由於被F影響。 2. bnd限制了root使用者exec後的邊界,docker就是對當前程序的bnd進行設定,避免在容器內root建立新程序而cap提升。
3. i的效果在普通使用者下體現,i和bnd決定了這個程序及後續普通使用者程序的邊界。 4. i影響新程序的p(和e),即使當前程序沒有了p/e,exec之後還是可以有,新程序的p/e和當前程序的p/e沒關係。 5. 對於普通使用者,檔案的e如果為0,一切都沒有意義。因此對於普通使用者來說,預設情況下沒有任何cap,一定要通過檔案的e來擁有許可權。因此檔案cap是僅針對普通使用者而設計的。root使用者在exec時完全忽略檔案cap。
docker run --cap_add --cap_drop的本質
1. docker修改bnd,並讓i等於bnd,這樣後續root使用者的邊界是bnd,普通使用者的邊界是i和bnd。 2. 丟掉其它能力,只保持預設14個,應付root的 3. docker exec只擁有docker容器的許可權,不能超過。
其它備註
1. e和p要同時去掉 2. i是exec不是fork,fork的完全繼承父程序。 3. 程序的capset只能修改自己的 4. bnd是通過prctl來修改的