20125102
一、實驗描述
Set-UID 是Unix系統中的一個重要的安全機制。當一個Set-UID程序運行的時候，它被假設為具有擁有者的權限。例如，如果程序的擁有者是root，那么任何人運行這個程序時都會獲得程序擁有者的權限。Set-UID允許我們做許多很有趣的事情，但是不幸的是，它也是很多壞事情的罪魁禍首。
因此本次實驗的目標有兩點：
1．欣賞好的方面，理解為什么Set-UID是需要的，以及它是如何被執行的。
2．注意壞的方面，理解它潛在的安全性問題。
二、實驗內容
這是一個探索性的實驗，你的任務是在Linux環境中和Set-UID機制”玩游戲“，你需要在Linux中完成接下來的實驗任務：
2.1 猜測為什么“passwd”，“chsh”，“su”，和“sudo”命令需要Set-UID機制，如果它們沒有這些機制的話，會發生什么，如果你不熟悉這些程序，你可以通話閱讀使用手冊來熟悉它們，如果你拷貝這些命令到自己的目錄下，這些程序就不會是Set-UID程序，運行這些拷貝的程序，觀察將會發生什么。
從上面的截圖可以看出：將passwd拷貝到/tmp/下，權限發生了變化（在原目錄下suid位被設置），復件沒有了修改密碼的權限。
對于“chsh”，“su”，和“sudo”命令，把這些程序拷貝到用戶目錄下，同樣不再具有root權限。
2.2 在linux環境下運行Set-UID 程序，同時描述并且解釋你的觀察結果
2.2.1 以root方式登錄，拷貝/bin/zsh 到/tmp, 同時設置拷貝到tmp目錄下的zsh為set-uid root權限，然后以普通用戶登錄，運行/tmp/zsh。你會得到root權限嗎？請描述你的結果
2.2.2 拷貝/bin/bash到/tmp目錄，同時設置/tmp目錄下的bash為Set-UID root權限，然后以普通用戶登錄，運行/tmp/bash。你會得到root權限嗎？請描述你的結果。
2.3 從上面步驟可以看出，/bin/bash有某種內在的保護機制可以阻止Set-UID機制的濫用。為了能夠體驗這種內在的保護機制出現之前的情形，我們打算使用另外一種shell程序——/bin/zsh。在一些linux的發行版中（比如Redora和Ubuntu），/bin/sh實際上是/bin/bash的符號鏈接。為了使用zsh，我們需要把/bin/sh鏈接到/bin/zsh。
2.4 PATH環境變量的設置
system(const char * cmd)系統調用函數被內嵌到一個程序中執行一個命令，system()調用/bin/sh來執行shell程序，然后shell程序去執行cmd命令。但是在一個Set-UID程序中system()函數調用shell是非常危險的，這是因為shell程序的行為可以被環境變量影響，比如PATH；而這些環境變量可以在用戶的控制當中。通過控制這些變量，用心險惡的用戶就可以控制Set-UID程序的行為。
下面的Set-UID程序被用來執行/bin/ls命令；然后程序員可以為ls命令使用相對路徑，而不是絕對路徑。
2.4.1 你能夠設置這個Set-UID程序運行你自己的代碼而不是/bin/ls嗎？如果你能的話，你的代碼具有root權限嗎？描述并解釋你的觀察。
可以具有root權限，把/bin/sh拷貝到/tmp目錄下面重命名為ls（先要確保/bin/目錄下的sh 符號鏈接到zsh，而不是bash），將環境變量PATH設置為當前目錄/tmp，運行編譯的程序test。就可以獲得root權限：
?
2.4.2 修改/bin/sh使得其返回到/bin/bash，重復上面的攻擊，你仍然可以獲得root權限嗎？描述并解釋你的觀察。
2.5 sytem()和execve()的不同
首先確保/bin/sh指向zsh
背景：Bob在為一家審計代理處工作，他正在調查一家公司是否存在詐騙行為。為了這個目的，他需要閱讀這家公司在Unix系統中的所有文件；另一方面，為了保護系統的可靠性，他不能修改任何一個文件。為了達到這個目的，Vince——系統的超級用戶為他寫了一個SET-ROOT-UID程序，并且給了Bob可以執行它的權限。這個程序需要Bob在命令行中打出一個文件名，然后運行/bin/cat命令顯示這個文件。既然這個程序是以root權限運行的，它就可以顯示Bob想看的任何一個文件。然而，既然這個程序沒有寫操作，Vince很確信Bob不能用這個程序修改任何文件
2.5.1 程序中有 q=0。程序會使用system()調用命令行。這個命令安全碼？如果你是Bob，你能對系統的完整性妥協嗎？你能重新移動一個對你沒有寫權限的文件嗎?
這個命令不安全，Bob可能會出于好奇或者個人利益驅使閱讀或者修改只有root用戶才可以運行的一些文件。比如截圖中：file文件只有root用戶有讀寫權限，但普通用戶通過運行該程序，閱讀并重命名了file文件：
2.5.2 如果令q=1；剛才的攻擊還會有效嗎？請描述并解釋你的觀察。
修改為q=1后，不會有效。前面步驟之所以有效，是因為system()函數調用/bin/sh，鏈接至zsh，具有root權限執行了cat file文件后，接著執行mv file file_new命令。
而當令q=1, execve()函數會把file; mv file file_new 看成是一個文件名，系統會提示不存在這個文件
2.6 LD_PRELOAD環境變量
為了保證Set-UID程序在LD_PRELOAD環境的操縱下是安全的，動態鏈接器會忽略環境變量，但是在某些條件下是例外的，在下面的任務中，我們猜測這些特殊的條件到底是什么。
2.6.1 把myprog編譯成一個普通用戶下的程序在普通用戶下運行
可見，它會使用LD_PRELOAD環境變量，重載sleep函數：
2.6.2 把myprog編譯成一個Set-UID root的程序在普通用戶下運行
在這種情況下，忽略LD_PRELOAD環境變量，不重載sleep函數，使用系統自帶的sleep函數：
2.6.3 把myprog編譯成一個Set-UID root的程序在root下運行
在這種情況下，使用LD_PRELOAD環境變量，使用重載的sleep函數
2.6.4在一個普通用戶下把myprog編譯成一個Set-UID 普通用戶的程序在另一個普通用戶下運行
在這種情況下，不會重載sleep函數：
由以上四種情況可見：只有用戶自己創建的程序自己去運行，才會使用LD_PRELOAD環境變量，重載sleep函數，否則的話忽略LD_PRELOAD環境變量，不會重載sleep函數。
2.7 消除和清理特權
為了更加安全，Set-UID程序通常會調用setuid()系統調用函數永久的清除它們的root權限。然而有些時候，這樣做是遠遠不夠的。在root用戶下，在/tmp目錄新建一個空文件zzz。在root用戶下將下面代碼命名為test.c，放在/tmp目錄下，編譯這個程序，給這個程序設置root權限。在一個普通的用戶下，運行這個程序。描述你所觀察到的情況，/tmp/zzz這個文件會被修改嗎？解釋你的觀察。
三、實驗遇到的問題
1、在第2.6.4步驟時，我遇到了更改myprog的權限不夠的問題
2、實驗要求攻擊完之后zzz文件里會有數據，但是自己操作的時候攻擊失敗了
四、實驗體會
? Set-UID?是Unix系統中的一個重要的安全機制。當一個Set-UID程序運行的時候，它被假設為具有擁有者的權限。例如，如果程序的擁有者是root，那么任何人運行這個程序時都會獲得程序擁有者的權限。Set-UID允許我們做許多很有趣的事情，但是不幸的是，它也是很多壞事情的罪魁禍首
??在本實驗中，由2.1及2.2步驟可以看出，/bin/bash有某種內在的保護機制可以阻止Set-UID機制的濫用，在2.3到2.5步驟可以發現，/bin/目錄下的sh?符號鏈接到zsh，將環境變量PATH設置為當前目錄/tmp，運行編譯的程序test，就可以獲得root權限，若修改sh連接回bash，運行test程序不能使普通用戶獲得root權限。
由步驟2.6可知道，只有用戶自己創建的程序自己去運行，才會使用LD_PRELOAD環境變量，重載sleep函數，否則的話忽略LD_PRELOAD環境變量，不會重載sleep函數。今后我一定會更加努力的學習linux相關知識，爭取對它有更好的掌握。
