Linux

大型安裝環境下應用程序安裝使用rpm和yum

  • July 19, 2014

我們非常大的組織已經開發了一個託管應用程序的標準,該標準規定應用程序及其所依賴的所有組件必須駐留在與作業系統本身不同的專用應用程序卷中。例如,如果應用程序是用 Perl 編寫的,我們需要在應用程序卷中維護一個單獨的 Perl 實例。

這背後的原因是作業系統和應用程序都依賴的那些組件可能而且經常確實有衝突的版本要求,並且強制應用程序維護自己的資源使得修補作業系統變得更加容易。此外,它還確保應用程序數據和日誌不會被塞入基於作業系統的工具所在的位置(例如,這對於 httpd 而言尤其重要)。

此外,除非存在有效且記錄在案的技術原因,否則應用程序程序必須以非特權使用者身份而不是 root 身份執行。我們在 Linux 中提供了解決方法,以便諸如 Web 伺服器之類的程序可以作為非特權使用者執行,並接受從特權埠(80 和 443)轉發到它們正在偵聽的非特權埠的連接。

從角度來看,我是我公司 Unix/Linux SA 組織的一名安全專家,我與平台技術支持專家密切合作,以維護和執行我上面列出的標準。我的大部分職責是通過集中管理的 sudo 審查特權訪問請求。我們的標準 Linux 是 Red Hat,但也正在考慮將 Ubuntu 和 CentOS 用於雲環境。

問題是我們目前正被應用程序團隊的請求轟炸,以允許他們(通過 sudo)使用 rpm 和 yum 安裝 Linux 應用程序,因為供應商需要這樣做並且無法提供任何替代方法來安裝應用程序。這在多個方面與我們的標準相衝突:

  • rpm 和 yum 工具必須以 root 權限執行。這意味著他們所做的一切都以 root 身份執行,因此必須經常在事後調整生成的安裝以允許它以非特權使用者身份執行。
  • 軟體包通常指定組件必須安裝在根卷中,而不是在指定的捲下。在可以指定包樹的根的地方,供應商通常堅持保持不變,因為他們只在包中指定的精確環境中對其進行了測試。
  • 最後,rpm 和 yum 從系統可用的任何儲存庫中提取依賴項,雖然我們要求應用程序使用我們的 Satellite 儲存庫來獲取 Red Hat 提供的任何東西,但供應商通常會提供他們自己的儲存庫,軟體必須包含這些儲存庫才能執行。

我的問題是,如何在這樣的環境中指定或限制使用 rpm 和 yum 以確保不會發生包衝突並可以安全地應用系統安全更新檔,同時又不完全禁止將這些工具用於應用程序軟體(直到現在我們一直在做並且發現這是徒勞的練習)?

在我們討論解決方案之前,先談談貴公司的安全標準。簡而言之,它們很難使用,而且已經過時以至於幾乎無關緊要。

很明顯為什麼它們很難使用,所以我不會再多說。

至於過時,很​​明顯它們沒有考慮到虛擬化、Linux 功能、容器、SELinux 等現代技術,所有這些都有助於以更優雅和可用的方式解決相同的安全問題。

例如,將 httpd 綁定到一個高埠,然後使用 iptables 將流量重定向到它,而不是像預設情況下那樣簡單地讓它綁定然後放棄特權,這近乎偏執,幾乎沒有任何好處。使用帶有 httpd 的 SELinux 也很複雜,因為這種設置不是在 httpd SELinux 策略的設計中設想的。

同樣,只是盲目地要求軟體包將自己塞入其中/opt/usr/local一無所獲,因為無論軟體包安裝在何處,RPM 已經保持了您所需的分離(除非軟體包損壞,第三方供應商軟體包可能就是這種情況,但這樣會拒絕安裝)並失去標準合規性,可能使相關的 SELinux 策略無法使用,並造成維護噩夢。Red Hat Software Collections是按照這些構想設計的,雖然它存在一些可用性問題,但在您處理實際問題時,通過這種設計建構您自己的軟體包可能是一種權宜之計。

不過,我看到的最大問題是維護一種“大型”伺服器或伺服器,每個人的應用程序都在其上並行執行。僅此一項就引入了自身的安全問題,這大概就是這些“安全實踐”的由來。虛擬化在這一點上已經相當成熟,簡單地將應用程序分離到它們自己的 VM 中,例如在 RHEL 6 或 RHEL 7 上使用 KVM,將消除對大多數這些“安全實踐”的需求。

按照這些構想,由於您幾乎可以肯定擁有大量應用程序,因此使用 OpenStack 創建私有云可能是您在中短期內的最佳選擇。這些將使用 RHEL 7 主機並執行 RHEL 7、6 甚至 5 個來賓,因為您可能有一堆還活著並且在踢的。它還將為您提供一個安全地試驗新應用程序和作業系統的平台,以及更輕鬆地按業務單位、部門等分配資源。

如果虛擬化對於某些事情來說太重了,那麼就轉向容器(例如RHEL 7 上的 LXC/Docker)。它們的重量要輕得多,除了應用程序包本身之外幾乎什麼都可以剝離,然後與它們自己的文件系統、網路和 uid/gid 命名空間隔離,有效地將它們與任何其他容器隔離開來,除非你碰巧在各自的防火牆。將 SELinux 添加到 KVM 虛擬機或 Linux 容器可提供第二層保護,只需點擊一下即可打開。

另外,如果您開始向他們提供 OpenStack 和/或 Docker,您的公司就會有很多開發人員會永遠愛您。

簡而言之,是時候評估現代 Linux 發行版及其提供的功能,並根據這些功能重新評估所有安全實踐。

在許可方面,Red Hat 現在提供無限制的虛擬化許可,允許您執行無限制的 RHEL 虛擬機/容器,當然還有 CentOS,它將在大約 99.9% 的時間裡替代 RHEL。所以那裡沒有任何藉口。

引用自:https://serverfault.com/questions/613744