app源碼開發(fā)公司英文網(wǎng)站seo
實現(xiàn)系統(tǒng)安全的策略
在Linux中,一切且為文件,實現(xiàn)系統(tǒng)安全的策略主要可分為兩種:基于inode
的安全、基于文件路徑的安全。
基于inode的安全
為文件引入安全屬性,安全屬性不屬于文件內(nèi)容,它是文件的元數(shù)據(jù),應(yīng)該與inode
關(guān)聯(lián),一些內(nèi)核安全模塊將安全屬性存儲在文件的擴展屬性中,這種方式就是基于inode
的安全?;?code>inode的安全的優(yōu)點主要有兩個:
- 文件的安全屬性與文件路徑無關(guān)。文件可以在不同目錄間移動,不管它怎么移動,其安全屬性都沒有變化。
- 同一個文件可以有多個鏈接,從不同鏈接訪問文件,其安全屬性總是一樣的。
基于inode
的安全的缺點是:
- 文件系統(tǒng)必須支持擴展屬性,并且掛載文件系統(tǒng)時必須使用擴展屬性。
- 刪除文件時,文件的安全屬性會隨之消失。再在原來的路徑處創(chuàng)建同名文件,并不能保證新文件和老文件的安全屬性相同。
- 安裝軟件和升級軟件需要保證系統(tǒng)中新的文件具有正確的安全屬性。新文件來自軟件包,新的安全屬性自然也應(yīng)該來自軟件包。于是就有了下一個要求:眾多軟件包格式也需要支持文件的擴展屬性,比如tar、cpio等。
基于inode
的安全實現(xiàn)策略有SELinux、SMACK等。
基于路徑的安全
從用戶角度看,用戶通過路徑訪問文件,用戶態(tài)進程無法用inode
號來訪問文件。即使是基于inode
的安全,用戶讀寫安全屬性也需先通過路徑找到文件,然后才能訪問文件的安全屬性。那么能否將文件的安全屬性簡單地與文件路徑對應(yīng)起來呢?比如/bin/bash
的安全屬性是“system-shell
”,/usr/local/bin/bash
的安全屬性是“local-shell
”。不把這些安全屬性存儲在文件的擴展屬性中,而是存儲在系統(tǒng)內(nèi)部的一張表里,這就是基于路徑的安全的實現(xiàn)原理。這樣做的優(yōu)點是:
- 不需要文件系統(tǒng)有額外支持。
- 不怕文件更新,對打包格式也沒有額外要求。用戶甚至可以為還不存在的文件定義安全屬性。
基于路徑的安全的缺點是:同一個文件可能有多個安全屬性,簡單地創(chuàng)建鏈接就可能讓文件擁有另一個安全屬性。
基于路徑的安全實現(xiàn)策略實現(xiàn)有Tomoyo、AppArmor等。
對文件讀取的安全策略
實現(xiàn)對文件讀取的安全策略也有兩種,一種是使用file_permission
鉤子函數(shù),另一種是使用inode_permission
鉤子函數(shù)。它們的區(qū)別如下:
inode_permission
和 file_permission
都與文件系統(tǒng)中的權(quán)限有關(guān),但是它們的作用和范圍不同。
inode_permission
是指針對文件 inode
的權(quán)限控制,而 file_permission
則是針對打開的文件描述符的權(quán)限控制。
當一個文件被創(chuàng)建時,系統(tǒng)為其分配一個 inode
(inode
存儲了文件的元數(shù)據(jù),如訪問時間、修改時間、權(quán)限等信息),在對該文件進行權(quán)限控制時,操作系統(tǒng)會檢查進程是否有訪問該文件 inode
的權(quán)限,如果權(quán)限不足則拒絕訪問。這部分的權(quán)限控制由inode_permission
完成。
而開發(fā)者在使用系統(tǒng)調(diào)用(如 open
、read
、write
等)打開文件時可以得到一個文件描述符,通過該描述符可以對打開的文件進行操作。在這里,系統(tǒng)會檢查該進程是否有訪問該文件描述符所代表的文件的權(quán)限,并在權(quán)限不足的情況下拒絕訪問。這部分的權(quán)限控制就是由 file_permission
完成的。
因此,inode_permission
和 file_permission
雖然都是與權(quán)限有關(guān),但是控制的范圍不一樣。inode_permission
主要關(guān)注于文件所在的 inode
層面,而 file_permission
則關(guān)注于打開的文件描述符層面,它們協(xié)同工作來保證文件的安全性。