第 7章 SEAM 參考

本章將介紹 SEAM 產品一部份的許多檔案、指令、及常駐程式。此外，其中還包括有關 Kerberos 辯證系統如何運作的詳細資訊。

下列為本章所含的參考資訊內容。

• "SEAM 檔案"

• "SEAM 指令"

• "SEAM 常駐程式"

• "SEAM 的辭彙"

• "辯證系統如何運作"

• "獲取一項使用 SEAM 的服務的存取權限"

• "使用 gsscred 表"

SEAM 檔案

PAM 設置檔案

SEAM 所附的預設 PAM 設置檔案，其中包括處理新 Kerberos 化應用程式的項目。新的檔案包括辯證服務、帳號管理、作業階段管理、及密碼管理模組等的項目。

rlogin、login、dtlogin、krlogin、ktelnet、及 krsh 的新辯證模組項目。以下為這些項目的範例。所有的服務都使用新的 PAM 程式庫，/usr/lib/security/pam_krb5.so.1，來提供 Kerberos 的辯證。

前三個項目採用 try_first_pass 選項，要求以使用者最初的密碼來辯證。使用最初的密碼表示即使列出多個機制，使用者也不會被提示輸入另一個密碼。

後三個項目則使用 acceptor 選項來防止 PAM 模組執行取得能賦予許可證的初始許可證的步驟。就 Kerberos 化 伺服器應用程式而言，應用程式已經執行此交換，因此不需要使用 PAM 來進行此步驟。此外，另外包含的一個 other 項目是作為所有需要辯證但尚未指定的項目之預設項目。

# cat /etc/pam.conf
 .
 .
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

在帳號管理方面，dtlogin 有一個使用 Kerberos 程式庫的新項目，如下所示。此外還包括一個 other 項目以作為預設的規則。目前 other 項目並未採取任何行動。

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
 other account optional /usr/lib/security/pam_krb5.so.1

/etc/pam.conf 檔案中的最後兩個項目如下所示。作業階段管理的 other 項目會損毀使用者的證書。而密碼管理的新 other 項目則會選擇 Kerberos 程式庫。

other session optional /usr/lib/security/pam_krb5.so.1 
 other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM 指令

本節列出包括在 SEAM 產品中的某些指令。

share 指令的變更

除了新的 SEAM 指令之外，SEAM 產品還包括了某些 share 指令變更，同時附在 Solaris 2.6 及 Solaris 7 的發行版中。share 指令可以使用三種新的安全模式﹕

krb5

選擇 Kerberos 辯證

krb5i

選擇有整合性的 Kerberos 辯證

krb5p

選擇有整合性及保密性的 Kerberos 辯證

share 指令中若包括多個模式，根據預設，如果客戶端並未指定一個安全模式，則會使用第一個列出的模式。否則就會使用客戶端選定的模式。

如果使用一個 Kerberos 模式的裝載要求失敗的話，則會使用 none 作為安全模式來完成裝載。NFS 客戶端之上的 root 主管沒有經過辯證時，經常會發生這種狀況。裝載要求也許會成功，但是使用者卻無法存取檔案，除非他們透過 Kerberos 來辯證。客戶端及伺服器之間的任何交換都需要 Kerberos 辯證，即使檔案系統並不是使用一個 Kerberos 安全模式所裝載的。

SEAM 常駐程式

SEAM 產品所使用的常駐程式列於下表中。

SEAM 的辭彙

下一節中將介紹 SEAM 說明文件中所用的辭彙及其定義。為了理解文件中的許多討論內容，請您務必深入瞭解這些辭彙及其涵義。

與辯證有關的辭彙

下面討論的辭彙有助於您瞭解整個辯證的過程。程式設計師和系統管理員應該儘量熟悉這些辭彙。

客戶端是指在一個使用者的工作站上執行的軟體。在客戶端上執行的 SEAM 軟體會在此過程中提出許多要求，因此有必要區分此軟體與使用者的動作。

伺服器及服務這兩個詞經常會交換使用。讓我們來加以說明﹕伺服器一詞是用來定義執行 SEAM 軟體的實際系統。而服務一詞則相應於一個伺服器所支援的一種特定功能（例如﹕ftp 或 nfs）。說明文件通常會將伺服器視為一項服務的部份，但此定義無法清楚地表達伺服器的真實意義；因此伺服器指的是實際的系統而服務則指的是軟體。

SEAM 產品包括三種密鑰類型。其中一個是 專用密鑰。此密鑰會提供給每一位使用者主管，而且只有主管使用者和 KDC 知道。使用者主管的密鑰是以使用者密碼為基礎的。而伺服器及服務的密鑰則是所謂的服務密鑰。此密鑰的目的和專用密鑰相同，但由伺服器和服務所使用。第三種類型的密鑰是一個作業階段密鑰。此密鑰是由辯證服務或能賦予許可證的服務所生成的。生成作業階段密鑰可以為一個客戶端和一項服務之間的交換提供額外的安全防護。

許可證是用來將一位使用者的身份安全地傳給伺服器或服務的一個資訊封包。許可證只適用於單一客戶端以及特定伺服器之上的一項特定服務。它包含服務的主管名稱、使用者的主管名稱、使用者主機的 IP 位址、一個時間戳記、以及一個定義許可證壽命的數值。許可證是以客戶端及服務所用的一個隨機作業階段的密鑰所建立的。建立一張許可證之後，在它過期之前，可以重覆使用此許可證。

證書是一個資訊封包，其中包括一張許可證以及一個相符作業階段的密鑰。證書通常會利用一個專用密鑰或是服務密鑰來進行加密，視哪一個要用來解密證書而定。

辯證器是另一種資訊類型。與一張許可證一起使用時，辯證器可以用來辯證一位使用者主管的身份。一個辯證器中包括使用者的主管名稱、使用者主機的 IP 位址、以及一個時間戳記。不像一張許可證，辯證器只能使用一次，通常是在要求存取一項服務時。辯證器是使用該客戶端及伺服器的作業階段密鑰來進行加密的。

許可證類型

許可證的內容可以監管其使用方式。這些內容是在建立許可證時指派的，不過您可以隨時修改一張許可證的內容。（例如，一張許可證可以由可轉遞的變更為轉遞的的）。您可以利用 klist 指令來檢視許可證的內容（請參見 "如何檢視許可證"）。

許可證可以分為下列幾種﹕

可轉遞/轉遞的

您可以從一個主機將一張可轉遞的許可證送到另一個主機，以免客戶端重新自我辯證。舉例來說，如果使用者 david 在 jennifer 的機器上取得一張可轉遞的許可證，他就可以登入自己的機器，而不需要申請新的許可證（因而再次自我辯證）。（請參見 "範例 - 建立一張許可證" 中可轉遞許可證的範例。）請將一張可轉遞的許可證與下方所示的可代理許可證做一個比較。

初始的

初始的許可證是一張直接核發的許可證，並不以能賦予許可證的許可證為基礎。某些服務，例如變更密碼的應用程式，可以要求將許可證標為初始的，以確保客戶端的確知道其保密性的密鑰內容-因為一張初始的許可證表明了該客戶端最近才經過自我辯證（而非依賴一張可能已經存在有一段時間的能賦予許可證的許可證）。

無效的

無效的許可證是一張尚未生效的遠期許可證。（請參見下方遠期的）它在被驗證之前會被一個應用程式伺服器所拒。要將一張無效的許可證驗證，在生效時間開始以後，客戶端必須將它附在一個 TGS 要求中提交給 KDC，並且設定 VALIDATE 旗標。

可遠期/遠期

遠期的許可證是一張在建立之後某特定時間才會生效的許可證。此種許可證很有用，例如，某些必須夜間才能執行的工作，就算其許可證被偷，也無法在要執行這些工作之前使用此許可證。核發一張遠期的許可證時，其狀態為無效的，一直要到其開始時間 KDC 要求客戶端驗證以後才會生效。（請參見上方無效的）一張遠期的許可證通常在能賦予許可證的許可證截止時間之前都有效。不過如果標明為可更新的話，其壽命通常被設定為與能賦予許可證的許可證的整個壽命一樣長。請參見下方的可更新。

可代理/代理

有時候主管必須允許一項服務來代表它執行某個操作。（例如當一位主管要求一項服務在第三個主機之上執行列印工作時。）這時服務必須成為客戶端的身份，只為了執行那一項單一操作。如此一來，伺服器就會被視為該客戶端的代理。在建立許可證時，必須指定代理的主管名稱。

除了只適用於單一服務之外，可代理許可證類似於一張可轉遞許可證，而可轉遞許可證則會將客戶端的身份整個都賦予代理服務。因此可以將一張可轉遞許可證視為某種超級代理。

可更新

因為壽命太長的許可證會產生安全上的顧慮，因此我們可以將許可證指定為可更新的許可證。一張可更新許可證有兩個截止時間﹕一是目前的許可證實例過期的時間，二是任何許可證的最長壽命。如果一個客戶端想要繼續使用同一張許可證，它可以在第一次截止之前將它更新。例如在一個小時之內有效的許可證，其最長壽命可以高達十個鐘頭。如果持有許可證的客戶端想要使用一個小時以上的話，客戶端必須在一個小時之內更新許可證。當一張許可證到達其最大的許可證壽命（10 小時）之後，會自動過期失效而無法再加以更新。

如需有關如何檢視許可證屬性的資訊，請見 "如何檢視許可證"。

許可證壽命

每當主管取得一張許可證，包括一張能賦予許可證-的許可證時，許可證的壽命會被設定為下列最小的壽命數值﹕

• 使用 kinit 來取得許可證時，kinit 的 -l 選項所指定的壽命值

• kdc.conf 檔案中所指定的最大壽命值 (max_life)

• Kerberos 資料庫中為提供許可證的服務主管所指定的最大壽命值。（在 kinit 一例中，服務主管為 krbtgt/ 範疇）

• Kerberos 資料庫中為要求許可證的使用者主管所指定的最大壽命值。

圖 7-1 會說明應如何決定一張 TGT 的壽命，以及這四種壽命值是如何而來。即使 圖 7-1 已說明一張 TGT 的壽命是如何得出，基本上任何主管取得一張許可證時也是同樣的情況。唯一的不同是 kinit 並不提供一個壽命值，而是由提供許可證的服務主管處取得最大壽命值（而非 krbtgt/ 範疇主管）。

圖 7-1 如何決定一張 TGT 的壽命

可更新許可證的壽命也是由四個數值中最小的一個來決定的，但下面情況則要使用可更新壽命值﹕

• kinit 的 -r 選項所指定之可更新壽命值，如果是以 kinit 來取得或更新許可證的話

• kdc.conf 檔案中指定的最大可更新壽命值 (max_renewable_life)

• Kerberos 資料庫中為提供許可證的服務主管所指定的最大壽命可更新值（在 kinit 一例中，服務主管為 krbtgt/ 範疇）

• Kerberos 資料庫中為要求許可證的使用者主管所指定的最大壽命可更新值

主管名稱

每張許可證都是依據主管的名稱來識別的。主管名稱可以識別一位使用者或是一項服務。以下為數個主管名稱的範例。

辯證系統如何運作

如果您可以提出一張證明您身份的許可證，以及一個相符的作業階段密鑰的話，應用程式就會允許您登入一個遠端系統。作業階段密鑰包含有關使用者及被存取的服務特定的資訊。KDC 會在所有使用者第一次登入時，為其建立許可證及作業階段密鑰。因此許可證及相符的作業階段密鑰就形成一張證書。在使用多網路的連線服務時，一位使用者可以同時搜集許多證書。使用者必須取得特定的伺服器之上執行的每項服務的證書。舉例來說，要存取一個名為 boston 的伺服器之上的 ftp 服務，需要一張證書，而存取 ftp 另一個伺服器之上的服務則需要其本身的證書。

建立與貯存證書的過程是透明化的。證書是由將證書送給提出要求之人的 KDC 所建立的。收到證書之後，它會被貯存在一個證書快取記憶體中。

獲取一項使用 SEAM 的服務的存取權限

為了讓一位使用者能夠存取特定的伺服器之上的特定服務，使用者必須取得兩樣東西。第一是一張能賦予許可證的服務（簡稱為 TGT）的證書。一旦能賦予許可證的服務將此證書解密之後，該服務便會建立使用者所要求存取的第二張伺服器證書。然後這第二張證書便可以用來要求伺服器之上服務的存取權限。在伺服器成功地解密第二張證書之後，使用者就會取得存取的權限。這整個過程將在下方詳細加以描述。

為能賦予許可證的服務取得一張證書

1. 要開始辯證的過程，客戶端必須向特定使用者主管的辯證伺服器提出要求。此要求是以未加密的狀態送出。因為要求中沒有任何安全性的資訊，所以就不需要加密。

2. 當辯證服務收到要求之後， KDC 資料庫中的使用者的主管名稱會被查詢。如果符合一位主管的話，辯證服務便會取得該主管的專用密鑰。然後辯證服務會生成一個作業階段密鑰，以供客戶端及能賦予許可證的服務（稱為作業階段密鑰 1）使用，並且生成一張許可證以供能賦予許可證的服務（許可證 1）使用。此許可證亦稱謂能賦予許可證的許可證 (TGT)。這兩個作業階段密鑰及許可證都是利用使用者的專用密鑰來加密的，然後便會將資訊送回給客戶端。

3. 客戶端會利用此資訊，以使用者主管的專用密鑰來解密作業階段密鑰 1 及 許可證。既然只有使用者和 KDC 資料庫知道此專用密鑰，封包中的資訊應該是安全的。客戶端將資訊貯存在證書快取記憶體中。

通常這時使用者會被提示要輸入其個人密碼。如果輸入的密碼和用來建構 KDC 資料庫中所存專用密鑰的密碼相同的話，客戶端就可以成功地解密辯證服務所送的資訊。那麼客戶端就有一張與能賦予許可證的服務配合使用的證書了。客戶端已經準備要求一張伺服器的證書。

圖 7-2 為能賦予許可證的服務取得一張證書

為一個伺服器取得一張證書

1. 在要求一個特定伺服器的存取權限時，客戶端必須先向辯證服務取得一張該伺服器的證書（請參見 "為能賦予許可證的服務取得一張證書"）。然後客戶端向能賦予許可證的服務提出要求，其中包括服務主管名稱、許可證 1、以及一個以作業階段密鑰 1 加密的辯證器。許可證 1 最初是由能賦予許可證的服務之辯證服務使用服務密鑰所加密的。

2. 因為能賦予許可證的服務之服務密鑰即是能賦予許可證的服務，因此便可以解密許可證 1。許可證 1 中的資訊包括作業階段密鑰 1，因此能賦予許可證的服務也可以解密辯證器。這時，便以能賦予許可證的服務來辯證使用者主管。

3. 一旦辯證成功之後，能賦予許可證的服務就會為使用者主管及伺服器（作業階段密鑰 2）生成一個作業階段密鑰，並且為伺服器（許可證 2）生成一張許可證。接著作業階段密鑰 2 及許可證 2 便可以使用作業階段密鑰 1 來加密。因為只有客戶端及能賦予許可證的服務知道作業階段密鑰 1，此資訊便可以安全地透過網路來傳送。

4. 當客戶端收到此資訊封包時，它會使用作業階段密鑰 1 來解密資訊，此密鑰一直被貯存在證書快取記憶體中。既然客戶端已經取得一張能與伺服器配合使用的證書，現在客戶端就可以要求該伺服器之上一項特定服務的權限存取。

圖 7-3 取得一張伺服器的證書

取得一個特定服務的存取權限

1. 要要求一項特定服務的存取權限，客戶端必須先向辯證伺服器取得能賦予許可證的服務的一張證書，並且向能賦予許可證的服務取得一張伺服器證書（請參見 "為能賦予許可證的服務取得一張證書" 及 "為一個伺服器取得一張證書"）。客戶端可以向伺服器送出一個要求，包括許可證 2 及另一個辯證器。辯證器是加密的使用作業階段密鑰 2。

2. 許可證 2 是能賦予許可證的服務以該服務密鑰所加密的。因為服務主管知道服務密鑰，該服務便可以解密許可證 2 並且取得作業階段密鑰 2。然後作業階段密鑰 2 可以用來解密辯證器。如果辯證器被成功解密的話，客戶端就會取得該服務的存取權限。

圖 7-4 取得一個特定服務的存取權限

使用 gsscred 表

當一個伺服器試著識別一位 SEAM 使用者的身份時，NFS 伺服器便會使用 gsscred 表。NFS 服務會利用 UNIX 識別碼來識別使用者，這些識別碼不是使用者主管或證書的一部份。gsscred 表可以提供從 UNIX UID（從密碼檔案）至主管名稱的對映。在您公開 KDC 資料庫之後就必須建立與管理此表格。

收到一個客戶端的要求時，NFS 服務會試著將主管名稱對映至一個 UNIX 識別碼。如果對映失敗，它就會參考 gsscred 表。一個 root/hostname 主管會自動以 kerberos_v5 機制來對映至 UID 0，此時就不會參考到 gsscred 表。這表示您無法利用 gsscred 表來特別重新對映 root。

選擇何種機制，為gsscred表

要為 gsscred 表選取正確的機制，有下列幾項考慮因素﹕

• 您是否想要改善查詢時間？

• 您是否想要增加資料的存取安全？

• 您是否需要很快地建構檔案？

下列為所有可供選擇的的後端機制，以及這些機制的優點說明。

檔案

gsscred 表儲存在一個檔案系統中。這個無法分享的本機檔案系統可以提供最安全的後端支援，因為在表格建立之後就沒有透過網路來進行任何的傳輸。本版的檔案建構時間最短。

xfn_files

gsscred 表儲存在 /var/fn 檔案系統中。您可以決定是否要分享此檔案系統。所有的 xfn 檔案都需要花很長時間來建構。

xfn_nis

gsscred 表儲存在 NIS 名稱空間。此檔案系統上的查詢並不安全。所有的 xfn 檔案都需要花很長時間來建構。

xfn_nisplus

gsscred 表儲存在 NIS+ 名稱空間。此檔案系統的查詢並不安全。所有的 xfn 檔案都需要花很長時間來建構。

xfn

gsscred 表儲存在 xfn 的預設系統中。所有的 xfn 檔案都需要花很長時間來建構。

檔案後端機制的初始查詢會很慢，而其他機制的初始查詢可以利用一個名稱服務來加快。就所有的機制而言，只要快取過資料之後，其擷取時間就會大同小異。