羅漢新，王金雙

（中國人民解放軍陸軍工程大學(xué) 指揮控制工程學(xué)院，江蘇 南京 210007）

0 引 言

Docker[1]是一種輕量級的虛擬化方式，將應(yīng)用程序和運行環(huán)境打包成容器鏡像，使得應(yīng)用程序能夠直接在容器中獨立地運行。由于Docker擁有輕量化、高效率和易部署的特點，目前已被廣泛應(yīng)用于云計算和微服務(wù)架構(gòu)中[2]。

根據(jù)國家安全漏洞庫[3]統(tǒng)計，Docker 自2013年正式發(fā)布以來，截至2022 年8 月，累計發(fā)現(xiàn)124 個相關(guān)漏洞，其中高危以上漏洞占71%，這對應(yīng)用生態(tài)安全和用戶信心都帶來了不利影響。因此，Docker 的安全性得到了產(chǎn)業(yè)界和學(xué)術(shù)界的廣泛關(guān)注，許多研究思路和方法被不斷提出。本文對Docker 安全相關(guān)的研究思路、方法和工具進行比較和分析，并指出未來可能的研究方向。

1 背景知識

1.1 Docker 架構(gòu)

圖1 為Docker 架構(gòu)圖。容器在宿主機上工作，并和其他容器共享宿主機內(nèi)核。其中Docker 客戶端和Docker 守護進程通過REST API進行通信，發(fā)送拉取鏡像之類的命令行請求；Docker 守護進程用來處理Docker 客戶端發(fā)送的請求；Docker 引擎是Docker 架構(gòu)中的運行引擎；Docker 容器是容器服務(wù)的交付實體。

圖1 Docker 架構(gòu)

1.2 Docker 安全機制

Docker 采用了多種Linux 內(nèi)核安全機制來約束容器內(nèi)的進程，如表1 所示。

表1 Docker 安全機制

Docker 利用Linux 的命名空間（Namespaces）為容器提供獨立的工作空間，與其他容器進行資源隔離；Docker 利用Cgroups 機制，限制每個容器可以訪問哪些資源，確保多容器環(huán)境下能正常使用系統(tǒng)資源；Capabilities 定義了CAP_CHOWN、CAP_KILL 等多種權(quán)限（不同版本略有不同，5.16-rc6 版本中定義了40 個權(quán)限），將超級用戶權(quán)限進行細(xì)分，容器默認(rèn)只有其中的14 種權(quán)限；Docker 基于Seccomp 機制，限制容器內(nèi)系統(tǒng)調(diào)用；SElinux 和AppArmor 屬于強制訪問控制，限制可執(zhí)行程序的訪問控制權(quán)限，如讀寫功能；內(nèi)容信任機制通過發(fā)布者簽名和使用者校驗的方式確認(rèn)鏡像的完整性。

2 容器Docker 安全風(fēng)險

狴犴安全團隊[4]將Docker 安全問題分為鏡像安全風(fēng)險、容器虛擬化安全風(fēng)險和容器網(wǎng)絡(luò)安全風(fēng)險3 個方面，本文在此基礎(chǔ)上對Docker安全問題進一步補充分析，為后續(xù)Docker 安全增強提供研究方向。

2.1 鏡像安全風(fēng)險

鏡像安全決定了生成容器的安全性，一直是學(xué)術(shù)界關(guān)注的熱點。表2 是近幾年研究鏡像包含漏洞的情況。隨著時間的推移，鏡像中的漏洞數(shù)并沒有明顯減少，說明鏡像倉庫中的鏡像安全問題一直沒有得到很好的解決。

表2 Docker 鏡像漏洞對比

（1）鏡像安全威脅模型[5]如圖2 所示，Docker Hub 平臺用戶面臨兩種不同的威脅：一是攻擊者可以發(fā)布包含惡意執(zhí)行命令的鏡像，一旦用戶下載運行鏡像，就可能遭受攻擊；二是開發(fā)者發(fā)布包含漏洞的鏡像，攻擊者有可能利用漏洞對使用鏡像的用戶進行攻擊。

圖2 Docker 鏡像安全威脅模型

（2）鏡像倉庫安全風(fēng)險。主要包含兩個方面的風(fēng)險：一是如果私有鏡像倉庫的配置不當(dāng)，攻擊者可利用漏洞直接通過公網(wǎng)訪問私有倉庫并隨意篡改倉庫鏡像；二是用戶以明文形式下載鏡像，容易遭遇中間人攻擊，攻擊者能夠篡改鏡像內(nèi)容或者冒名發(fā)布惡意鏡像。

（3）構(gòu)建鏡像安全風(fēng)險。兩種Docker 鏡像的構(gòu)建方式：一是使用Docker commit 命令行方式構(gòu)建，直接提交容器并生成鏡像；二是編寫Dockerfile 指令，按照指令構(gòu)建一個新鏡像。文獻[5]研究表明，Docker Hub 平臺上的Dockerfiles 文件存在兩個問題：一是構(gòu)建過程違背Dockerfile 最佳實踐，如未明確標(biāo)記鏡像版本等；二是Dockerfiles 文件包含惡意代碼腳本，導(dǎo)致存在主機文件泄露等安全問題。

2.2 容器虛擬化安全風(fēng)險

容器是一種輕量級的虛擬化方式，且不擁有獨立的資源配置，沒有做到系統(tǒng)內(nèi)核層面的隔離。

（1）容器隔離安全風(fēng)險。與虛擬機相比，Docker 缺少虛擬化層，在文件隔離方面并不完善，如容器仍然可以訪問主機系統(tǒng)的/proc 和/sys 目錄，攻擊者可以獲取/proc/kallsyms 中的內(nèi)核符號來構(gòu)建針對內(nèi)核漏洞的攻擊。針對存儲資源，Cgroups 未對主機存儲資源進行限制。若容器不斷向存儲空間寫入數(shù)據(jù)直至耗盡，將造成主機或容器的拒絕服務(wù)。

（2）容器逃逸攻擊。容器逃逸是指容器“逃出”自身權(quán)限，能夠?qū)λ拗鳈C和其他容器進行非法訪問[6]。容器逃逸的方式有很多種：一是利用容器的配置不當(dāng)，如Docker 高危啟動參數(shù)等；二是利用Docker 軟件本身存在的安全漏洞，如容器逃逸著名案例Shocker 攻擊[7]通過調(diào)用open_by_handle_at 函數(shù)來獲取宿主機的資源；三是利用內(nèi)核漏洞進行容器逃逸，如通過內(nèi)核漏洞非法進入內(nèi)核上下文，獲取當(dāng)前進程的有關(guān)數(shù)據(jù)，切換當(dāng)前命名空間來獲取root shell，實現(xiàn)容器逃逸。

2.3 容器網(wǎng)絡(luò)安全風(fēng)險

Docker 網(wǎng)絡(luò)驅(qū)動包含橋接網(wǎng)絡(luò)、MacVLAN和Overlay 這3 種模式[8]，如圖3 所示。Docker默認(rèn)的網(wǎng)絡(luò)驅(qū)動是橋接網(wǎng)絡(luò)。

圖3 Docker 網(wǎng)絡(luò)驅(qū)動

橋接網(wǎng)絡(luò)的容器之間共用未過濾的Docker0網(wǎng)橋來進行通信；MacVLAN 與主機的網(wǎng)絡(luò)接口連接，容器之間沒有訪問權(quán)限限制；Overlay 主要利用虛擬擴展局域網(wǎng)（Virtual eXtensible Local Area Network，VXLAN）技術(shù)，在主機之間的網(wǎng)絡(luò)上構(gòu)建出新的虛擬網(wǎng)絡(luò)，但未實現(xiàn)流量加密。3 種組網(wǎng)模式都存在一定的安全風(fēng)險，容器易遭受地址解析協(xié)議（Address Resolution Protocol，ARP）欺騙、嗅探、廣播風(fēng)暴和拒絕服務(wù)等攻擊，造成敏感信息泄露和網(wǎng)絡(luò)服務(wù)功能受限等危害。

容器之間的網(wǎng)絡(luò)流量控制主要利用Iptables命令進行基于IP 的訪問控制。但是容器的IP是動態(tài)的，創(chuàng)建或重新啟動容器會分配一個新IP，Iptables 命令都需要調(diào)整。因此，從性能和安全性兩方面為容器指定安全策略是一個挑戰(zhàn)，因為每當(dāng)重新創(chuàng)建容器時，必須更新這些策略，并且在策略更新期間也應(yīng)鎖定Iptables的策略表。此外，Iptables 的限制范圍有限，容器網(wǎng)絡(luò)仍然容易受到數(shù)據(jù)鏈路層攻擊，如ARP 欺騙等。每個容器需要不同的網(wǎng)絡(luò)策略，策略的總數(shù)將隨著容器數(shù)量的增加而增加，容易產(chǎn)生網(wǎng)絡(luò)策略爆炸，容器生態(tài)系統(tǒng)的性能和安全性都將受到影響。

3 Docker 安全增強技術(shù)

Docker 安全增強技術(shù)主要包括利用Linux 內(nèi)核安全機制、可信計算的單容器安全增強，以及基于訪問控制策略容器間運行安全控制等。

（1）基于命名空間和內(nèi)核模塊（Linux Kernel Module，LKM）來緩解容器隔離安全風(fēng)險。Jian 等人[6]通過動態(tài)檢查主機命名空間的方式，實現(xiàn)了對異常進程的有效檢測，防止逃逸行為。陳莉君等人[9]提出了基于LKM 的Docker 資源信息隔離方法，利用系統(tǒng)調(diào)用劫持技術(shù)來覆寫進程文件內(nèi)容，建立有效的資源隔離機制。

（2）基于AppArmor 機制增強容器安全，緩解了容器逃逸和特權(quán)提升等攻擊。在AppArmor 的默認(rèn)配置文件中并沒有限制網(wǎng)絡(luò)和capability 規(guī)則，攻擊者可以通過受損容器危害宿主機。Loukidisandreou 等人[10]提出Docker-Sec 方法，通過靜態(tài)分析容器執(zhí)行參數(shù)和動態(tài)監(jiān)測運行狀態(tài)來生成AppArmor 配置文件，但該方法無法防御用戶空間攻擊。Mattetti 等人[11]提出了LiCShield 框架，利用SystemTap 方法跟蹤系統(tǒng)內(nèi)核操作并生成包含5 種規(guī)則的AppArmor 配置文件，但LiCShield 生成的文件作用范圍只在Docker 守護進程。Zhu 等人[12]提出的Lic-Sec將Docker-Sec 與LiCShield 相結(jié)合，動態(tài)分析生成AppArmor 配置文件。其能夠提供更高級別的保護，防止所有的特權(quán)提升攻擊，包括Docker-Sec 無法防御的用戶空間攻擊。Lic-Sec 的流程如圖4 所示。

圖4 Lic-Sec 流程

（3）基于Seccomp 機制增強容器安全。在Linux 的300 多個可用系統(tǒng)調(diào)用中，Seccomp 默認(rèn)會在配置文件中阻止其中44 個系統(tǒng)調(diào)用，但剩余的系統(tǒng)調(diào)用仍有可能被濫用從而對系統(tǒng)造成安全威脅。Lei 等人[13]提出了分階段執(zhí)行應(yīng)用程序容器SPEAKER，將容器分成啟動階段和運行階段，使用strace 工具對系統(tǒng)調(diào)用進行跟蹤并生成Seccomp 配置文件，但是動態(tài)分析無法覆蓋容器全部的系統(tǒng)調(diào)用。Wan 等人[14]提出了一種基于自動測試的沙箱容器挖掘方案（Mining Sandboxes），使用測試套件對容器進行測試并跟蹤系統(tǒng)調(diào)用，分析日志生成Seccomp 配置文件，同樣動態(tài)分析無法覆蓋容器全部的系統(tǒng)調(diào)用。Ghavamnia 等人[15]提出Confine 工具，使用靜態(tài)和動態(tài)分析來檢測出容器內(nèi)的應(yīng)用程序及其所有依賴項，識別容器正確操作所需的系統(tǒng)調(diào)用，并生成Seccomp 配置文件?；贏ppArmor 機制和Seccomp 機制的6 種方法的具體比較如表3 所示[10-15]。

表3 基于Linux 內(nèi)核安全機制的加固方法

（4）基于可信計算增強容器安全。2015 年，Intel 推出指令集擴展（Software Guard Extensions，SGX）[16]，可用于保護不受信任主機上運行的容器和其他應(yīng)用程序。Arnautov 等人[17]提出了基于SGX 機制增強Linux 容器安全（Secure Linux Containers with Intel SGX，SCONE）來保護容器免受外部攻擊，但是該方法對于硬件設(shè)備的限制過高，無法進行大范圍推廣。王鵑等人[18]利用可信計算技術(shù)，提出了Docker 安全增強系統(tǒng)DockerGuard，構(gòu)造了一條從底層硬件到容器的信任鏈，增強運行過程的安全。但該方案犧牲了Docker 容器原有的便捷、快速部署的特性，并且難以根據(jù)Docker版本的更新進行實時更新。

（5）微服務(wù)環(huán)境中的容器間訪問控制。云服務(wù)應(yīng)用程序通常由許多微服務(wù)組成，而73%的微服務(wù)部署在容器當(dāng)中。為了防止正常的微服務(wù)被其他惡意的微服務(wù)隨意訪問，需要有細(xì)粒度的訪問控制策略來支撐。Li 等人[19]提出了自動增強訪問控制工具AUTOARMOR，具有以下特點：一是利用基于靜態(tài)分析的請求提取機制，從微服務(wù)源碼中自動獲取微服務(wù)間的調(diào)用邏輯；二是利用基于圖形的策略管理機制，通過權(quán)限圖來實現(xiàn)策略的更新。實驗表明，AUTOARMOR 能夠以較小的開銷有效地生成微服務(wù)間的訪問控制策略，成功阻止了訪問未經(jīng)授權(quán)的微服務(wù)、訪問未經(jīng)授權(quán)的資源和執(zhí)行未經(jīng)授權(quán)的操作3 種未經(jīng)授權(quán)請求攻擊，緩解了容器網(wǎng)絡(luò)安全風(fēng)險。但該方法仍存在以下問題：一是請求識別依賴于服務(wù)間通信庫的建立和語義模型，當(dāng)通信庫的建模不完整時，會導(dǎo)致請求不被識別；二是即使通信庫建模是正確的，無用代碼也會帶來誤報。

4 Docker 安全檢測

4.1 檢測容器安全工具

鏡像安全風(fēng)險一直是學(xué)術(shù)界的研究熱點。目前的鏡像安全檢測工具主要分為開源工具和商用工具。本文對代表性的開源工具進行性能對比，如表4 所示[20-24]。

表4 檢測容器安全工具

Javed等人[25]使用Clair、Anchore和Microscanner這3 種掃描工具對59 個承載Java 應(yīng)用程序的容器進行掃描，發(fā)現(xiàn)現(xiàn)有的工具準(zhǔn)確性普遍不高，準(zhǔn)確率最高的Anchore 漏掉了34%的漏洞，原因是只有Anchore 能夠掃描非系統(tǒng)包，同時準(zhǔn)確率依賴于現(xiàn)有的漏洞數(shù)據(jù)庫和漏洞檢測方式。Zheng 等人[26]介紹了一種基于繼承圖的安全檢測系統(tǒng)ZeroDVS，通過2 000 個鏡像的rootfs 配置信息，建立有鏡像繼承關(guān)系的圖形數(shù)據(jù)庫，并預(yù)先存儲父鏡像信息。在掃描鏡像漏洞時，與數(shù)據(jù)庫匹配批量識別父鏡像源的漏洞，此時只需掃描未匹配的子鏡像層的安全漏洞，提高了安全掃描效率。

4.2 基于機器學(xué)習(xí)的容器安全檢測

容器安全檢測工具大多是針對鏡像進行靜態(tài)掃描檢測?；跈C器學(xué)習(xí)的檢測技術(shù)主要是對容器運行時的狀態(tài)（系統(tǒng)調(diào)用、文件輸入/輸出、網(wǎng)絡(luò)輸入/輸出、調(diào)度程序和內(nèi)存等）進行特征提取，然后使用分類器進行訓(xùn)練檢測。檢測技術(shù)分為無監(jiān)督學(xué)習(xí)檢測方法和有監(jiān)督學(xué)習(xí)檢測方法。

（1）無監(jiān)督學(xué)習(xí)檢測方法。Tunde-onadele等人[27]發(fā)現(xiàn)僅對容器進行靜態(tài)漏洞掃描是不夠的，于是提出了4 種無監(jiān)督機器學(xué)習(xí)方法，包括K 近鄰法（K-Nearest Neighbor，KNN）、主成分分析（Principal Component Analysis，PCA）結(jié)合KNN、K 均值（K-Means）、自組織映射算法（Self-Organizing Map，SOM），把系統(tǒng)調(diào)用頻率作為特征向量，通過實驗比較，SOM 的檢測準(zhǔn)確率最好，達到78.57%，但都沒有達到較高的準(zhǔn)確率。Srinivasan 等人[28]提出了一種實時入侵檢測系統(tǒng)模型，利用N-grams 系統(tǒng)調(diào)用計算概率，然后使用最大似然估計器和簡單良好的圖靈平滑技術(shù)來處理跟蹤，檢測異常的準(zhǔn)確率可達到87%～97%。

（2）有監(jiān)督學(xué)習(xí)檢測方法。Abed 等人[29]將系統(tǒng)調(diào)用包（Bag of System Calls，BoSC）與滑動窗口技術(shù)結(jié)合，只跟蹤當(dāng)前窗口中系統(tǒng)調(diào)用的頻率，把規(guī)定窗口內(nèi)不同的系統(tǒng)調(diào)用的頻率映射成序號，并作為特征向量來進行判別訓(xùn)練。該方法具有較高的檢測率，真陽性率達到100%，但該方法對訓(xùn)練要求高。Tien 等人[30]提出KubAnomaly 系統(tǒng)，使用4 層全連接層構(gòu)造神經(jīng)網(wǎng)絡(luò)，利用系統(tǒng)調(diào)用作為特征向量來創(chuàng)建分類模型，實現(xiàn)了高達96%的檢測準(zhǔn)確率，并成功識別了4 次真實環(huán)境下的攻擊。但應(yīng)用該系統(tǒng)需要在客戶機上安裝代理軟件，可能會面臨通過代理軟件進行攻擊的威脅。季一木等人[31]利用基于系統(tǒng)調(diào)用序列和系統(tǒng)調(diào)用頻率的入侵檢測方法，結(jié)合滑動窗口與優(yōu)化后的詞的逆文檔頻率（Term Frequency–Inverse Document Frequency，TF-IDF）算法提取系統(tǒng)調(diào)用特征，通過對比特征相似度進行分類。得出的實驗結(jié)果表明，該方法檢測準(zhǔn)確率高達99.71%。但該方法只能預(yù)測容器內(nèi)是否出現(xiàn)異常操作，未能對異常進行分類和規(guī)避。

4.3 基于溯源圖的容器安全檢測

溯源圖技術(shù)[32]能夠細(xì)粒度地跟蹤系統(tǒng)的數(shù)據(jù)流，是全面安全監(jiān)控和對歷史攻擊行為建模的有效手段。但容器的命名空間機制使數(shù)據(jù)流中引入了碎片和模糊性。碎片是指頂點分裂，導(dǎo)致溯源圖中的節(jié)點錯誤連接。模糊性是指頂點合并，其中一個頂點表示溯源圖中的多個不同對象。

Hassan 等人[33]提出Winnower 工具能夠?qū)⑦M程從不同的容器中區(qū)分開來，但是缺少命名空間感知，導(dǎo)致容器內(nèi)的溯源圖連接斷開。Pasquier 等人[34]提出CamFlow 工具能夠生成命名空間感知的溯源圖，但是不能有效地捕獲基本的容器語義（即容器邊界），無法判斷溯源子圖屬于哪一個容器。

Chen 等人[35]提出利用CLARION 工具來解決命名空間帶來的挑戰(zhàn)。針對PID 命名空間帶來的影響，可以使用內(nèi)核數(shù)據(jù)結(jié)構(gòu)獲取主機與容器之間PID 的映射；針對Mount 命名空間帶來的影響，可以使用與chdir 關(guān)聯(lián)的當(dāng)前工作目錄查找容器根目錄的主機路徑，在文件路徑上建立主機容器映射；針對Network 命名空間帶來的影響，設(shè)計了一個基于Netfilter 的解決方案，用于跟蹤主機容器IP/端口映射；針對IPC 命名空間帶來的影響，向每個IPC 對象添加一個IPC命名空間ID，可以唯一區(qū)分來自不同容器的IPC 對象。實驗表明，該工具能夠生成正確的容器溯源圖，在容器內(nèi)的攻擊能夠被準(zhǔn)確地檢測和溯源。

4.4 基于鏡像標(biāo)簽的容器安全檢測

2018 年殷康[36]的研究表明在鏡像倉庫中，大部分鏡像標(biāo)簽并沒有指定版本號，導(dǎo)致用戶可能下載同一個鏡像名的不同版本的惡意鏡像?；诖?，作者設(shè)計出一種面向Docker 鏡像的標(biāo)簽自動推薦方法，該方法基于Dockerfile 相似度和基于標(biāo)簽的隱含狄利克雷分布（Labeled Latent Dirichlet Allocation，L-LDA）模型，實現(xiàn)了一種多模型融合的鏡像標(biāo)簽推薦方法。針對10 萬個Dockerfile 文件，該方法能夠提升25.6%的鏡像構(gòu)建成功率，同時能識別正確的鏡像版本號并完成下載，提高了用戶使用鏡像的安全性。

2022 年Liu 等人[37]研究了關(guān)于容器注冊中心的注冊表拼寫的安全問題。作者通過精心構(gòu)造鏡像的標(biāo)簽，并將該鏡像上傳至鏡像倉庫，實驗表明，用戶確實存在因標(biāo)簽拼寫錯誤而拉取作者上傳的鏡像。因此，作者提出了CRYSTAL工具，利用收集到的鏡像標(biāo)簽數(shù)據(jù)打包成文件供CRYSTAL 查詢，幫助容器注冊中心發(fā)現(xiàn)潛在的拼寫錯誤的鏡像標(biāo)簽，在用戶下載鏡像時，提醒用戶是否存在拼寫錯誤并提供正確的標(biāo)簽選項。作者實現(xiàn)了CRYSTAL 的原型，達到了97.5%以上的檢測率，提高了用戶使用鏡像的安全性。由于CRYSTAL 工具在Docker 命令行上實現(xiàn)，所以對于其他拉取鏡像的方式，如使用Dockerfile 文件拉取鏡像，CRYSTAL 工具無法檢測使用，下一步將CRYSTAL 工具擴展到注冊表，進一步緩解因拼寫錯誤而下載惡意鏡像的風(fēng)險。

5 Docker 鏡像瘦身

容器鏡像通常被構(gòu)建在其他鏡像上，使得鏡像代碼量逐步增加，軟件規(guī)模不斷擴大且復(fù)雜性顯著增加，導(dǎo)致容器性能下降，安全漏洞增加。優(yōu)化鏡像大小常用的方法是在構(gòu)建Dockerfile時通過命令來縮減鏡像體積大小，如多階段構(gòu)建等。Docker 官方推出了一款開源的縮減工具Docker-Slim[38]。Docker-Slim 通過鏡像的歷史信息，來獲取生成鏡像的Dockerfile 文件及相關(guān)的配置信息。通過內(nèi)核工具解析出鏡像中必要的文件和文件依賴，將這些必要文件重新構(gòu)建成新鏡像，其體積最大程度能夠縮減30 倍。Rastogi等人[39]提出Cimplifier 工具，根據(jù)最小權(quán)限原則將一個容器劃分成若干個小容器，每個小容器只運行一個簡單應(yīng)用程序。利用系統(tǒng)調(diào)用日志映射出所需的資源，在可執(zhí)行文件級別上對其進行分區(qū)，容器大小可減少58%～95%。減少不必要的文件就相應(yīng)地減少了攻擊者能夠利用的攻擊面，緩解了容器鏡像安全風(fēng)險。

6 結(jié) 語

本文對Docker 架構(gòu)以及基本安全特性進行介紹，分析了Docker 面臨的安全威脅，對Docker 增強、安全檢測、瘦身等方面的安全技術(shù)進行了分析梳理。但Docker 安全問題還有許多待解決的問題值得深入研究[6,40]：一是研究漏洞評估工具的可用性，研究和對比容器的漏洞掃描器性能、可用性、自動化性以及與當(dāng)前部署和編排工具的集成問題，需解決0-day、1-day帶給Docker 的重大安全威脅；二是開發(fā)有效、實用和在線的安全補丁解決方案，因為容器在打補丁后需要重啟，導(dǎo)致服務(wù)器（如Web 服務(wù)器）產(chǎn)生業(yè)務(wù)斷開；三是關(guān)注物聯(lián)網(wǎng)等資源共享和受限場景下的容器安全問題。