Linux系統中掩耳盜鈴的sudo配置_linux shell

 今天在這裡討論Linux系統中一個非常滑稽的系統配置失誤，就是sudo，為什麼說是滑稽的配置呢，就是因為如果配置不當的話，普通使用者非常容易就可以提權到root使用者，而且沒有一點技術含量，系統管理員自己以為已經做好了許可權管理，其實如果配置不當，許可權漏洞已經出現。

　　很多公司Linux系統都會用到sudo來配置普通使用者可以執行的超級使用者權限，一是為了系統管理員更安全的作業系統，二是可以為研發人員提供可控的許可權範圍，下面就看一下我們在系統中常見的sudo設定檔。

複製代碼 代碼如下:

admin ALL=(ALL) NOPASSWD: /app/nginx/sbin/nginx

　　這一段設定檔顯示admin使用者可以通過sudo來調用root許可權啟動nginx，相信這也是經常使用sudo的功能之一，因為如果nginx啟動的是80連接埠的話，普通使用者是無法啟動的，因為系統限制了1024以下的連接埠監聽只有root許可權才可以操作，問題大多出現在這個sbin目錄下的nginx可執行檔上，因為我們既然要將nginx的系統管理權限交付給普通使用者admin，那麼大部分情況是nginx的所有檔案許可權所屬使用者及組也都為admin，就像下面顯示的這樣。

複製代碼 代碼如下:

[admin@localhost sbin]$ ll
總用量 3004-rwxr-xr-x 1 admin admin 3066035 9月  10 2014 nginx

　　但是如果sbin目錄下的nginx檔案許可權也為admin使用者，而此時該檔案還在sudo許可權配置中，那麼問題就來了，admin使用者可以將系統任意命令copy過來變成nginx檔案，到這裡大家應該知道潛在的風險是有多大了，只要是任何命令檔案admin使用者有唯讀許可權，那麼就可以把檔案變成nginx，隨意以root身份執行該命令，因為sudo只關心執行的檔案名稱，而不關心檔案內容本身，如果此時admin使用者需要提權到root使用者下也很簡單，只要將系統的vi命令copy到sbin目錄下並重新命名為nginx，當檔案替換後，此時的nginx檔案就變成了系統的vi命令，如果admin使用者此時運行sudo nginx時就是以root使用者的許可權來執行vi動作了，例如使用者執行sudo nginx /etc/sudoers，他就可以用root身份來編輯這個檔案，從而給自己開放一個NO PASSWORD ALL的許可權，只要儲存sudo設定檔，執行sudo su -就可以輕鬆切換到root許可權中來了，而後再將被替換的nginx檔案複原，此時用root許可權就可以輕鬆留下系統後門，同時再清空操作記錄，完成整個操作而不留痕迹，下面來總結一下admin提權需要的幾步操作。

[admin@localhost ~]$ sudo -l使用者 admin 可以在該主機上運行以下命令：

複製代碼 代碼如下:

    (ALL) NOPASSWD: /app/nginx/sbin/nginx
[admin@localhost ~]$ which vi
/bin/vi
[admin@localhost ~]$ cp /bin/vi /app/nginx/sbin/nginx
[admin@localhost ~]$ sudo /app/nginx/sbin/nginx /etc/sudoers   //注意此時已經是調用root許可權vi編輯sudoers檔案了
[admin@localhost ~]$ sudo -l使用者 admin 可以在該主機上運行以下命令：
    (ALL) NOPASSWD: ALL
[admin@localhost ~]$ sudo su - root
[root@localhost ~]#   //使用者成功切換到root許可權

　　避免這樣的問題發生其實也很簡單，就是將我們需要執行的檔案所屬許可權都改為root即可，這樣普通使用者就沒有辦法用copy的方法來改寫這個檔案，因為他對於該檔案已經沒有操作許可權了，從而也就規避了這種提權風險。

　　最後提一下發現這個配置問題的過程，在很早剛開始負責營運工作時，那個時候還是在一家傳統互連網企業，甲方對於許可權的控制非常嚴格，對於系統操作人員只提供普通使用者權限，如果普通使用者需要操作apache或者是nginx等就需要配置sudo，由於申請root許可權的流程非常繁瑣，在一次非常緊急的系統故障處理中就發現了這個方法，而當時的sudo可執行檔就存在許可權所屬的問題，最終提權成功了，不過這種方法還是不鼓勵大家去做哈，如果在生產系統中發現有這樣的問題，應該及時更新修複，避免由於許可權泄漏導致的更多問題。