共用方式為

Longhorn 中的安全性：專注于最低許可權

  • 發行項

 

Keith Brown
DevelopMentor

2004 年 4 月

適用於：
   2003 專業開發人員會議 (PDC) 「Longhorn」 預覽版組建

總結： Longhorn 承諾是最低許可權應用程式的絕佳平臺。 首先，請先撰寫 Managed 程式碼，開始使用。 建置傳統型應用程式時，請讓它們符合 LUA 規範 (，並使用 Windows 應用程式驗證器來協助檢查您的工作) 。 (11 個列印頁面)

目錄

問題
應用程式和部署資訊清單
LUA：最低許可權使用者帳戶
(已淘汰) Power Users 群組
AIM：應用程式影響管理
PA：受保護的系統管理員
Longhorn 上的受控應用程式
「沒有風險」許可權集合
工具
總結

我一直都是以最低許可權執行的提倡者。 許多知道我已聽說開發人員在開發程式碼時，應該結束以系統管理許可權執行的許可權，但前提是只協助鼓勵更多應用程式在最低許可權環境中執行。 因此，我很滿意 2003 Microsoft 專業開發人員會議 (PDC) ，下一版 Windows® 作業系統的程式碼命名為 「Longhorn」 的主要目標之一，就是讓使用者更容易以最低許可權執行。

問題

當您在本機軟體商店購買 Microsoft Windows XP® Professional 的複本，並將它安裝在電腦上時，安裝精靈會為您和將使用該電腦的任何其他人建立帳戶。 Windows XP 開機之後，它會顯示一個相當歡迎畫面，其中顯示每個使用者的名稱，並允許他們登入。 這些使用者預設都是電腦的系統管理員。 原因為何？ 因為若不是如此，使用者體驗會很差。

使用者預期能夠在其電腦上安裝軟體，但除非您是系統管理員，否則您無法安裝現今軟體的 90%。 使用者預期軟體在沒有當機的情況下執行，但除非使用者是系統管理員，且這是開放式數位，否則 70% 的軟體將無法正常執行。 很糟的是，這些應用程式在非系統管理環境中大量失敗，只是因為它們對於儲存應用程式狀態的位置有不良選擇。 Program Files 目錄不是儲存狀態的位置。 這是儲存程式的位置—可執行檔。 儲存應用程式狀態的位置稱為 使用者設定檔，而為了儲存共用使用者狀態，「所有使用者」設定檔就已足夠。 Windows 標誌計畫指導方針會說明這一點，但現今大部分的 Windows 軟體是在不考慮 Windows 標誌指導方針的情況下開發的。

但是，您可能會詢問使用者是否應該以非系統管理員身分執行，特別是主使用者？ 沒錯，如果實際上很容易執行，住家使用者就會獲得好處。 惡意程式碼 (病毒、病毒、病毒或其他惡意程式碼) 喜歡具有系統管理許可權。 以系統管理員身分流覽網頁或讀取電子郵件，這幾天只是一般危險。 您的兒童呢？ 是否適合讓他們在主機電腦上安裝及播放遊戲，知道他們不會意外中斷某些專案、安裝間諜軟體，或移除您強制執行的內容分級限制？ 以這種方式思考：以系統管理員身分執行，實際上會關閉 Windows 所提供的大部分安全性保護。 家用和公司使用者不應該關閉這些保護，特別是在連線到網際網路時，這已成為危險鄰近地區。

讓使用者和他們執行的程式在最低許可權環境中快樂地上線，將會大幅增加 Windows 平臺的安全性。

應用程式和部署資訊清單

Longhorn 引進的一個重要功能是應用程式和部署資訊清單的概念。 前者可讓應用程式開發人員指出其應用程式正常運作所需的許可權，後者可讓系統管理員指定他們在應用程式中放置多少信任。 這些資訊清單還多於這一點，但我想要指出它們可供 Managed 和 Unmanaged 應用程式使用，以及其存在的主要原因，是協助使用者以最低可能的許可權執行應用程式。

若要深入瞭解這些資訊清單，請參閱 Brent Rector 簡介 「Longhorn」 for Developers書籍第 1 章。

LUA：Least-Privilege使用者帳戶

LUA 或 最低許可權使用者帳戶是一項縮寫，我確定您現在會在 Microsoft 簡報中看到重複的重複。 PDC 2003 簡報者通常會將縮寫發音為 「looah」。它並不美觀，甚至沒有任何新專案。 LUA 是指標對互動式使用者和服務使用非特殊許可權使用者帳戶的做法。

Longhorn 小組想要簡化安全性。 他們認為系統應該有兩個層級的存取權：最低許可權和系統管理。 他們甚至已取代 Power Users 群組， (在 Longhorn 中稱為「admin-lite」) 。

當 Power Users 群組消失後，應用程式開發人員真的需要做出選擇。 他們需要決定哪些層級的許可權 (LUA 或系統管理) Longhorn 的應用程式需求。 如果應用程式不需要系統管理許可權，則應該謹慎寫入，以在最低許可權帳戶下運作。 這表示測試 (，甚至是撰寫程式碼) 使用一般使用者帳戶。 例如，LUA 應用程式應該以安全的位置寫入資料檔案，例如使用者設定檔，而不是 Program Files 目錄樹狀結構。 但未針對 Longhorn 重寫的應用程式會發生什麼事？ 如果這些應用程式在 Windows XP 上未以最低許可權帳戶執行良好，該怎麼辦？ 名為 Application Impact Management (AIM) 的 Longhorn 功能或許可以協助這些應用程式在 LUA 下執行，因為您很快就會看到。

(已淘汰) Power Users 群組

如果您認為系統管理帳戶具有「高」存取權，而一般使用者帳戶具有「低」存取權，則 Power 使用者帳戶可以說是具有「中」存取權。 Power Users 群組允許讀取和寫入檔案系統和登錄的元件，這些帳戶通常限制在最低許可權帳戶 (，也就是不保留特殊許可權群組成員資格的一般使用者帳戶，例如系統管理員或 Power Users) 。 許多嘗試以一般使用者身分執行的人發現，他們決定將其帳戶新增至 Power Users 群組時失敗，這幾乎修正了他們遇到的所有問題。 但它們不再以最低許可權真正執行。 例如，在 Windows XP 上，使用此「中」許可權層級執行的任何惡意程式碼，都將允許危害儲存在 Program Files 目錄中的其他應用程式、以特洛伊木馬程式取代信任的 COM 元件等等。 下一次使用者在這類遭入侵的電腦上以她的系統管理帳戶執行時，您可以確定惡意程式碼也會透過先前安裝的特洛伊木馬程式執行。 因此，您不會取得以 Power User 身分執行的任何實際保護。

AIM：應用程式影響管理

Longhorn 小組認為以最低許可權執行非常重要。 他們想要有相當歡迎的畫面包含主要由最低許可權帳戶組成的使用者帳戶清單。 但它們也會以腳部為實境。 就像現今許多主要軟體完全忽略 Windows 標誌計畫一樣，Longhorn 時間範圍內大部分的主要軟體也可能會忽略 LUA 方案。 未格式化的應用程式開發人員會繼續撰寫軟體，以從 Program Files 目錄樹狀結構讀取和寫入資料檔案。 它們也會繼續將登錄資料寫入HKEY_LOCAL_MACHINE，而不是HKEY_CURRENT_USER。 如果必須完全使用登錄，則前者是一般使用者寫入的限制，因此後者最好用來儲存應用程式設定。

當 Windows XP 偵測到應用程式需要更多許可權 (這很罕見，但偶爾會發生安裝程式) ，它會通知非特殊許可權的使用者，應用程式需要系統管理許可權才能執行，方便彈出對話方塊來收集系統管理員帳戶的使用者名稱和密碼。 然後，程式會在指定的帳號下執行。 但是這不一定可以運作，因為許多應用程式不會寫入為安裝在一個帳戶下，並在另一個帳戶下使用。

Longhorn 採用完全不同的方法。 Longhorn 偏好在 LUA 下執行應用程式，而不是鼓勵使用者提高許可權，讓應用程式能夠正常運作。 但是，當應用程式嘗試寫入HKEY_LOCAL_MACHINE或 Program Files 目錄樹狀結構時，會發生什麼事？ Longhorn 會使用寫入複寫原則，為應用程式提供其自己嘗試變更之資源的虛擬化檢視。 當應用程式嘗試寫入 Program Files 目錄中的檔案時，Longhorn 會為應用程式提供自己的檔案私人複本，而且可以合作。 如此一來，在 AIM 案例中鬆散的任何惡意程式碼都可能會嘗試覆寫 Program Files 目錄樹狀目錄樹狀目錄下常用的可執行檔，或許WINWORD.EXE。 但最後會覆寫的內容是只有惡意程式碼可以看到的私人複本。 使用者看到的WINWORD.EXE版本仍會是原始、未限制的版本。

不要依賴 AIM 來儲存您。 撰寫您的應用程式，以從第一天開始在 LUA 下執行。

PA：受保護的系統管理員

即使每個應用程式都必須在 Longhorn 時間範圍內修正，以在 LUA 下執行，仍然會有真正需要系統管理許可權的應用程式。 其中包括備份軟體、硬碟重組和重新分割軟體、企業管理軟體，以及清單等公用程式。 因此，在某個時間點，使用者必須使用系統管理帳戶來完成特定工作。 讓我們來看看，許多人員都會忽略建立 LUA 帳戶的建議，並只要以系統管理員身分執行即可。

Longhorn 小組設計了整齊的配置，可協助您在系統管理帳戶下執行時加以保護。 這是一項稱為 「受保護的系統管理員」的功能，當它開啟時，您一律可以在系統管理帳戶下執行，並覺得相當安全，因為您執行的大部分應用程式都會以特殊受限制的權杖來執行，其權杖類似于您在 LUA 案例中擁有的權杖。 只有您已「無力」的應用程式，或貴公司已部署並指定為受信任的應用程式，將會使用完整的系統管理權杖執行。 將應用程式指定為受信任的其中一種方式，就是簽署其部署資訊清單。 為什麼很實用？ 給我一個範例。

通常以系統管理員身分執行的使用者會開啟她的 Longhorn 電子郵件用戶端，並開始流覽電子郵件。 她遇到來自自己知道的人的郵件，並開啟附件。 她很少知道她的朋友最近受到電子郵件感染，而此郵件包含惡意程式碼。 當惡意程式碼執行時，它會發現它在系統上具有非常少的許可權。 它無法修改 Program Files 目錄樹狀目錄中的任何專案。 它無法在 HKEY_LOCAL_MACHINE 下變更 COM 物件註冊。 這並不表示它無法執行任何不良動作，但這種情況比惡意程式碼本身以系統管理許可權執行的情況更好。

但等候，我沒有說使用者在執行電子郵件應用程式時以系統管理員身分執行？ 是，事實上就是這種情況。 但電子郵件應用程式未指定為「無用」系統管理應用程式;事實上，它是以 LUA 應用程式的形式撰寫。 因此，它收到受限制的權杖，因此惡意程式碼會如此。 這是最低許可權的整個點。 如果您因為不小心執行一些軟體而失去系統控制權 (，或可能是因為您剛按一下錯誤的功能表項目) ，則損毀將會受到限制或完全防止。

某些有安全性意識的系統管理員目前已實作此原則。 我是其中一個。 我有兩個帳戶，一般帳戶和一個系統管理帳戶。 當我需要以某種方式管理系統時，以一般使用者身分登入，偶爾切換至我的系統管理帳戶，例如在我的電腦上新增虛擬目錄、在 Microsoft SQL™ Server 中建立資料庫等等。 (如果您想知道，即使開發 software.) Longhorn 小組已正式化此方法，在受保護的系統管理員 (PA 中，在簡短) 功能中，我最終仍花費大約 95% 的時間。 這表示我只要以系統管理員身分執行，但仍以最低許可權執行。 不再切換來回切換兩個使用者設定檔，依此類推。

如果這聽起來很整齊的想法，而且您想要協助人員實際使用這項功能，則您必須仔細撰寫以最低許可權執行的應用程式。 因為如果啟用這項功能，所以即使系統管理員執行此功能，需要比它所需的許可權更多的應用程式，還是會不必要地中斷，除非它被指定為受信任的系統管理員應用程式。 當然，AIM 可能會帶回您的修復，但您不應該依賴它，因為 Microsoft 估計 20% 的應用程式可能無法透過 AIM 讓 LUA 相容。 如果您遇到此 20% 的情況，您的應用程式將無法執行。 如果發生這種情況就足夠，沒有人會使用受保護的管理員功能，這確實是一件非常難的事。

其他優點將會隨著寫入以最低許可權執行的更多應用程式而出現。 例如，公司最終將能夠鎖定其工作站，讓員工能夠以最低許可權帳戶執行。 這可大幅簡化系統管理並降低成本。 現在，請務必撰寫具有最低許可權執行的應用程式。 您可以在此平臺上產生差異。

Longhorn 上的受控應用程式

PDC 2003 的其中一個訊息是受控應用程式未來。 藉由撰寫 Managed 程式碼，您可以利用 Windows 平臺上安全性的最新創新：透過程式碼識別的安全性。 Common Language Runtime 所提供的辨識項型安全性系統 (CLR) ，通常稱為 CAS 或「程式碼存取」安全性，可讓 CLR 根據程式碼的來源、簽署者等等，對程式碼進行額外的限制。 這個新增的安全性維度會開啟軟體發佈的新途徑。 藉由在安全沙箱中執行程式碼，用戶端現在可以放心地執行從中央伺服器下載的程式碼，讓這類功能「沒有觸控」和「按一下一次」部署可行，進一步降低系統管理成本。 而且，如果部署和安全性風險類似，誰不想在機器上執行真正的 Windows 應用程式？

在 Longhorn 中，每個受控應用程式都可以指出它所需的特定許可權，以便透過應用程式資訊清單運作。 程式代碼清單 1 顯示當我建置預設精靈產生的 「Longhorn Application」 專案時所產生的範例資訊清單。 請注意 TrustInfo 區段和在該處表示的許可權集。 這些是應用程式需要執行的許可權。

程式代碼清單 1。 應用程式資訊清單

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

符合 LUA 規範的受控應用程式一律會包含如下的區段，而 Longhorn 中的信任管理員會使用此資訊來判斷是否允許在電腦上安裝應用程式。 如果應用程式經過仔細編碼，則可能能夠以這類低許可權執行，信任管理員可以將它指派為「無風險」分數，而且可以立即安裝並執行應用程式，而不需使用者介入。 不過，如果應用程式根據要求的許可權評分更危險的風險評等，則會提示使用者顯示描述應用程式所造成潛在危險的對話。 然後，使用者可以選擇是否允許安裝並執行應用程式。

在資訊清單中預先說明您的意圖是個不錯的主意，因為如果您不是，信任管理員只能假設應用程式最差，而向使用者表示的風險評等看起來會愈好。 因此，最好在資訊清單中表達您需要的許可權。 請勿略過此步驟。

在 PDC 2003 所述的研究中，Microsoft 發現當顯示 ActiveX 控制項下載警告等安全性對話方塊時，40% 的使用者一律按一下 [否]。 很明顯地，如果您想要透過網際網路將軟體散發給使用者，您會希望 Longhorn 中信任管理員的風險評等為「無風險」，因此在安裝和執行應用程式之前，不會提示使用者。 因此，您可能想知道是否有一組記載的許可權，一律會「沒有風險」評分。它發現有這類定義，也稱為 SEE 許可權集合。

「無風險」許可權集合

您可能已經聽過 PDC 2003 中稱為 SEE (Secure Execution Environment) ，但大部分的人都發現該字詞相當混淆，因此我只會將此稱為 無風險許可權集合。 Longhorn 會隨附特殊許可權集合，一律會以 Longhorn 中的預設信任管理員為「無風險」評分。 如果您撰寫的許可權需求完全落在無風險許可權集合內的應用程式，則可以安裝並執行它，而不會顯示任何信任警告。 只有在此集合內授與許可權的程式碼至少 (Microsoft 一開始定義，) 就不能刻意或意外損害您的電腦。

因此，如果您想要讓應用程式安裝並執行，而不提示使用者出現令人驚驚的對話方塊，您會想要將自己限制為此許可權集合所允許的活動。 您應該知道 Longhorn 小組正在考慮讓系統管理員可設定此許可權集合，因此，某個月臺上被視為「沒有風險」的專案可能會在另一個月臺上有所不同。 但對於大部分的 Longhorn 安裝而言，沒有風險的許可權集合將是隨附于作業系統的預設許可權集合。

其外觀為何？ 另一個查看程式代碼清單 1 中的資訊清單。 請注意，指定給 TrustInfo 區段中定義 之 PermissionSet 的識別碼，「SeeDefinition」。

以下是 PDC 2003 預覽組建的無風險許可權集合外觀：不受限制的 FileDialogPermission 可讓您透過標準 OpenFileDialog 和 SaveFileDialog 類別來讀取或寫入使用者選擇的檔案，但您無法瞭解使用者檔案系統的結構，包括使用者選擇的檔案名。 IsolatedStoragePermission可讓元件在使用者的硬碟上讀取和寫入最多 5 MB 的使用者特定狀態，而不需要提示她輸入檔案對話方塊。 SecurityPermission可讓您的程式碼在第一個位置執行。 UIPermission可讓您在畫面上繪製，但只能在自己的視窗中繪製，並授與您有限的剪貼簿存取權， (您無法以程式設計方式讀取其內容，但使用者可以從剪貼簿貼到控制項) 。 PrintingPermission 可讓您列印，但只有在您透過列印對話方塊進行列印時。 您的程式碼無法以無訊息方式啟動列印工作，而使用者知道您正在執行。 「Avalon」特定許可權可讓您的程式碼建立全螢幕視窗，只要它們具有由作業系統控制的框線 (，您就無法詐騙登入畫面，例如) 。

請記住，此定義幾乎會隨著時間而變更;它甚至可能會在 Longhorn Beta 出貨之前變更。 因此，請在這裡使用 Salt 的粒紋來說明我的描述。 希望本文可協助您開始查看.NET Framework中的一些最低許可權功能，例如隔離儲存體和一般對話，因為最終定義沒有風險的許可權集可能會要求您使用這些功能以避免信任對話。

定義無風險的許可權集合不是簡單的工作。 Longhorn 小組知道其定義是否太嚴格，沒有足夠的應用程式可以使用它。 但如果太寬鬆，惡意程式碼絕對會誤用它。 其中一個希望小組可以找到最愛的地方。 圖 1 是一個圖表，顯示 Longhorn 應用程式的許可權範圍，從無所求的系統管理員應用程式到設計以使用 SEE 許可權集合執行的應用程式。

Aa480194.leastprivlh01 (en-us，MSDN.10) .gif

圖 1. 應用程式類型

工具

建置最低許可權的應用程式從未十分簡單。 您需要有指導方針和工具來協助。 我們在 PDC 2003 看到這些工具的一些範例，其中第一個範例是 Visual Studio® 2005 (PDC 2003 時間範圍內名為 「Whidbey」 的程式碼) 。

這個新的開發環境提供一些功能，可協助更輕鬆地以最低許可權環境為目標。 例如，您可以選擇您想要在偵錯應用程式時強制執行的許可權集合。 Longhorn 應用程式開始的絕佳位置是 SEE 許可權集合。 對於現有的應用程式，您的最佳選擇是以網際網路許可權集合為目標，這非常接近目前定義 SEE 的方式。

一旦您開始使用縮減的許可權進行偵錯，您就確定遇到一些非預期的 SecurityExceptions。 圖 2 顯示傳統範例，其中開發人員會使用檔案對話方塊提示使用者輸入檔案名，然後嘗試讀取指定的檔案名。 如果您被授與 FileDialogPermission (，因為您在 SEE 許可權集合中) ，這可讓您提示使用者輸入檔案，但您特別不允許看到使用者選取的檔案名。 相反地，您必須呼叫方法 (OpenFile) ，以開啟您接著可用來從檔案讀取的資料流程。 Visual Studio 2005 提供建議，協助開發人員找出使用 OpenFileDialog 類別的正確方式，以避免安全性例外狀況。

Aa480194.leastprivlh02 (en-us，MSDN.10) .gif

圖 2. 更好的工具支援

PDC 2003 宣佈的另一個公用程式稱為 PermCalc。 這是一種命令列工具，可評估元件，並透過啟發學習法判斷其執行所需的許可權。 這項功能也計畫包含在 Visual Studio 2005 中。 這是以最低許可權環境為目標的絕佳方式。 目前存在的類似工具稱為 Windows 應用程式驗證程式，這是 Windows 應用程式相容性工具組的一部分。 此工具可協助您偵測應用程式何時違反寫入檔案系統或登錄受保護部分等規則。

總結

Longhorn 承諾成為最低許可權應用程式的絕佳平臺。 首先，請先撰寫 Managed 程式碼，以開始使用。 建置傳統型應用程式時，請使其符合 LUA 規範 (，並使用 Windows 應用程式驗證器來協助檢查您的工作) 。 如果可以，請立即以網際網路許可權集合為目標，而且在 Longhorn 隨附時，您可能會適合使用 SEE。

詳細資訊

閱讀 Brent Rector 的書籍，介紹適用于開發人員的 「Longhorn」。

 

關於作者

Keith Brown 是一位獨立顧問，負責應用程式安全性。 他撰寫了程式設計Windows 安全性 ( Addison-Wesley 2000) ，並撰寫適用于 .NET 程式設計人員的新安全性書籍。 在 線上 http://www.develop.com/kbrown 閱讀新書籍。