Linux 要不要防毒？權限保護不了供應鏈風險

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-14

Linux 用戶常聽到「不需要防毒」這句話，但它很容易令人低估風險。XDA Developers 近日以 Arch User Repository（AUR）受惡意套件影響的事件為例，指出 Linux 的確有較嚴格的權限機制，下載回來的檔案通常不會自行執行；不過，只要用戶自行授予執行權限、輸入 sudo 密碼，或安裝未仔細核對的第三方套件，防線便會由系統設定轉移到人的判斷。這個界線對使用 Linux 桌面、WSL、個人伺服器或開發環境的人尤其重要。

原報道提及，攻擊者在 2026 年 6 月藉由接管被棄置的 AUR 套件、改動建置指令，令安裝流程拉取名為 atomic-lockfile 的 npm 套件，藉此投放近似 rootkit 的惡意程式；報道同時引述 Sonatype 的估計，約有 1,500 個 AUR 套件受波及。這是單一報道所轉述的數字，本文不把它延伸為整個 Linux 生態的普遍比例；但事件本身足以說明，攻擊者未必需要突破 Linux 核心，亦可把目標放在開發者日常信任的套件來源與安裝鏈。

權限機制減少意外執行，並非驗證來源

Linux 預設通常不會把新下載的檔案標示為可執行，使用者要先明確執行相關操作，程式才可運行；系統目錄亦會限制一般帳戶直接寫入。原報道以 Ubuntu 與 WSL 的命令列測試描述，嘗試直接執行一行腳本或在受保護位置建立檔案時，系統會因權限不足而拒絕。這類設計的價值，在於減少用戶單靠下載或開啟檔案便觸發惡意程式的機會，也限制低權限程式任意修改系統。

不過，權限管理回答的是「這個帳戶可否做某件事」，不是「這段程式碼是否安全」。當用戶為方便安裝而執行 curl 或 wget 下載的腳本，再接上 shell；或在看不懂內容下以 sudo 運行安裝指令，系統得到的訊號就是授權。對自架服務、home lab 與開發工作流程而言，這一點比桌面防毒提示更關鍵：有權限的惡意安裝程式可以讀取該帳戶可存取的憑證、設定檔和專案資料，後果視乎帳戶權限與機密管理方式而定。

因此，把 Linux 的安全歸因於「使用者較少」並不完整。較小的桌面市場規模或會影響大規模散播型攻擊的誘因，但程式庫帳戶、SSH 金鑰、雲端 token 與部署憑證，對針對性攻擊仍有價值。尤其開源專案往往依賴大量維護者、鏡像站、套件庫及相依套件，攻擊者只要在其中一環取得信任，便可能借正常更新或安裝途徑接觸下游用戶。這是供應鏈風險，靠「Linux 本身較安全」的印象很難處理。

ClamAV 的角色是掃描，不是代替審核

原報道在 Ubuntu 安裝 ClamAV，更新資料庫後以 EICAR 測試檔驗證，掃描器能即時報告 EICAR 簽名。EICAR 是供防毒產品測試偵測功能的無害測試檔，這個結果只支持一項有限結論：掃描器能按已知特徵辨識該測試樣本。它不能推導為 ClamAV 能辨認所有新型惡意程式，更不能證明某個套件在安裝前後必然安全。

防毒掃描仍有合理用途，例如檢查電郵附件、外來下載檔，或在共享儲存與 server 上篩查已知惡意檔案，亦可避免 Linux 主機無意間保存或轉送已知的 Windows 惡意檔。可是，簽名式偵測對剛出現、經混淆處理，或藏於看似正常的建置流程內的威脅，仍有明顯盲點。實際取捨是，掃描會增加一道檢查，但掃描沒有發現問題，不等同來源可靠；兩者屬不同層面的判斷。

對個人用戶而言，是否常駐掃描器可按使用情境決定；對會安裝社群套件、執行第三方腳本或接收大量外部檔案的人，按需要用掃描器檢查會較有意義。更穩妥的基本做法包括保持系統與套件更新、優先使用發行版官方倉庫、確認套件維護者與來源、檢視近期更新改動，以及避免把不明指令直接交給 sudo。這些措施未必完全消除風險，卻能收窄攻擊者濫用信任鏈的空間。

開發與自架環境要把「便利」列入威脅模型

WSL 用戶、學生和開發者常在教學文章、GitHub README 或論壇回覆中複製安裝指令；自架 server 的管理者亦可能為求快速部署而加入第三方套件庫。這些行為本身很常見，問題在於每次新增 repository、全域安裝 npm 套件，或以管理員身分執行腳本，都是把新的信任對象帶入環境。若腳本日後被更改、原作者帳戶失守，或相依套件被接管，原本一次性的方便可能成為持續風險。

較實際的下一步，是把安裝前檢查變成習慣：先看指令將下載甚麼、會否要求 root 權限、套件由誰維護，以及更新時有哪些檔案與相依項目被改動。對存有金鑰和部署憑證的環境，亦應減少日常帳戶可直接接觸的敏感資料。隨着針對套件供應鏈與憑證的攻擊持續受關注，值得觀察的將是發行版、套件平台和個別專案如何加強維護權轉移、更新審核與來源驗證；用戶端的安全習慣仍會是其中一環。