精選文章、推薦的最近更新

LibreOffice 使用技巧大集合

序：到了大學，我相信有很多做報告的機會，我基於踩了幾次雷，加上我是個在電腦使用方面有些背骨的人，身邊的人都用WIndows、MacOS，而我就算有WIndows我還是用Linux（目前是Ubuntu，這個發行版還不錯用）。其中，用LibreOffice的人少之又少，所以我想分享我...

2026年7月6日 星期一

AppArmor和簡單的電腦安全採取行動

　　之前在Facebook上（可以參考：https://www.facebook.com/share/p/1CtEefWjXb/）看到有人說Linux就是不安全（因為那一陣子不少人用AI挖到不少Linux的漏洞），進而有人說Windows才是最安全的，下面當然有不少網友去和該留言者吵架，我也不例外，結果我被說我是抖M，這下子我的火都起來了，我和他吵了近一週，我逐句懟回去，最後他都沒有懟我、也沒有懟別人。我其實之前就有試著把玩一下AppArmor，結果弄得Firefox不能正常使用，因此暫時作罷，我在Windows 11裡面把所有的安全功能都打開了（Secureboot是因為關不掉），像是記憶體隔離之類的都打開了，我也想來加強我的Linux環境（其實Debian、Ubuntu提供的AppArmor的預設就很夠用了，不會像Fedora的SELinux那樣過於激進）

我覺得被懟是M有些不大好，我認為覺得Linux反人性是因為被windows塑造，覺得用起來麻煩是因為選錯發行版（新手就用Arch Linux，當然會覺得麻煩啊），若是選擇Ubuntu，可以幫助熟悉使用終端機，選擇Linux Mint或是openSUSE基本就可以擺脫終端機，也不會太麻煩。我也想反問，修改登錄檔、使用PowerShell跑一下命令怎麽鮮少聽到有人說這是麻煩、是缺點？

 

CPU安全檢查 

　　其實電腦硬體或多或少都是有漏洞的，我這裡主要是展示一下怎麽查看自己電腦的CPU有哪些漏洞，以及怎麽解讀這一份安全報告。 

  1. 首先，我們可以在終端機輸入
    grep -r . /sys/devices/system/cpu/vulnerabilities/ 
  2. 接著你可以看到
    我的輸出範例。其實就是去抓取/sys/devices/system/cpu/vulnerabilities/目錄下有哪些已知的CPU漏洞以及目前採取的策略
     
  3. 我們可以留意每一個漏洞後面的說明
    Not affected：目前沒有這個漏洞
    Vulnerable：已知存在的漏洞，但目前沒有策略去應對
    Mitigation：已知存在的漏洞，並且已經有策略去應對 
  4. 以我來說，我的CPU目前的漏洞都有對應的緩解策略並且漏洞不多，是初步的好消息。已知的漏洞如下（詳細請閱讀我在〈參考資料〉引用的文章）：

    spectre_v1：處理器的分支預測執行時的漏洞，使得惡意程式可以透過監聽處理器執行False分支洩露的資料。

    spectre_v2：處理器在處理間接跳轉時，若快取不存在跳轉路徑的絕對位置而需要從記憶體讀取，此時處理器會把間接跳轉指令的絕對位置和目標路徑的絕對位置寫在BTB緩衝區（Branch Target Buffer）裡面，因為其他程式是可以共用同一區塊的BTB緩衝區，這就產生了漏洞。AMD CPU有專門的修正策略，叫做Full AMD retpoline，我的是Intel CPU，採取的是IBRS修復策略（Intel提出的），主要是在適當情況下清掉BTB緩衝區的資料。

    vmscape：CPU打開虛擬化技術，理論上電腦在執行虛擬機時，環境是絕對隔離的，但實際上是有一些例外的，使得虛擬機裡面的惡意程式滲透到實體機上進行感染。

    reg_file_data_sampling：這主要是Atom處理器分支會遇到的漏洞，而這個分支是大小核處理器的E核（我的筆電是大小核設計），這個漏洞是允許惡意程式根據先前的浮點寄存器（floating point registers）、向量寄存器（vector registers,）、整數寄存器（integer registers）的資料來反推之前的資料。

    spec_store_bypass：這是因為部分資料會放在記憶體並且和處理的快取同步（理論上），但為了效率，處理器會預測這個區塊的內容，進而繞過從記憶體取資料的過程（記憶體的速度是跟不上處理器的處理速度），但這個過程在記憶體的資料是有機會被惡意程式竊聽的。 
　　不知道大家有沒有發現，這些安全漏洞大多和「預測」有關。這裡就體現出效率和安全的抉擇，開啓預測，如果預測成功，就可以更快的執行完程式，但也有一些漏洞會被利用，這是我在高中社團課從中哥老師學到的：「凡事有好必有壞，我們要衡量好好的一面和壞的一面，做好取捨……。」 

存取控制 

　　主要有兩大類別，分別是強制訪問控制（mandatory access control, abbr. MAC）和自由選定存取控制（discretionary access control, abbr. DAC）。前者是統一透過作業系統來進行權限的授予、控制，因此程式要做什麼事情都是需要向作業系統申請、依照規定做事；後者是根據這個執行程序的使用者（主體）或是從屬的主體（客體）來決定對目標物可以有的權限，也因為部分的進程主體具有授權個這個主體分發執行進程的權限的賦予能力，這就是自主的地方。舉例來說，A進程在MAC下，權限要根據操作系統的安全準則下執行；但在DAC下，A進程可以有的權限可以根據本身或是執行它的主進程B來決定（B可以進行授權A的動作），B可以允許A進行授權其他A可能會用到的進程。值得留意的是，UNIX或是類UNIX的核心設計是基於DAC操作（我們規定這些目錄的讀取、操作權限），而安全模組的用意是用來補充這個DAC，換言之，在 Linux 核心中，LSM（Linux 安全模組，如 AppArmor/SELinux）是疊加在 DAC 之上的二重把關，但地位比 DAC 更高。 

　　而AppArmor是屬於MAC控制，因此我們有著一套強大的中心管理工具，同樣地也有SELinux。AppArmor主要是Debian/Ubuntu系列，SELinux主要是Fedora/RHEL系列，而openSUSE原本是AppArmor後來改為SELinux（目前是可以二則一，但開始往SELinux遷移）。理論上SELinux更加安全，但沒有AppArmor容易上手（這部分是大多人的評價，我主要是Debian系列，自然就選擇AppArmor，看個人啦。但根據我使用防火牆的經驗，Debian系列主推的ufw確實比Fedora系列主打的firewalld還要好上手） 

　　而AppArmor是基於檔案路徑限制，透過建立一套規則，規定每個處理程序可以訪問、操作的路徑（你還別說，要查看CPU占用本身也是可以抓取系統文件直接讀取就有的，可以看飛蚊話的這個影片〈哲学的魅力 | 非Windows系统家族的魅力之所在：“一切皆文件”〉，而SELinux是使用標籤，這部分不是我的專業（我連業餘都算不上），我就先略過了（推薦參閱鳥哥私房菜的這一篇〈SELinux 初探〉）。 

準備工作 

　　我們需要先安裝apparmor相關工具，一般來說都內建了。我們可以使用「apt list -i | grep apparmor」來查看我們是否安裝apparmor和apparmor-utils這兩個套件，若沒有就手動安裝一下apparmor、apparmor-utils、auditd（可選）。 

基本操作 

  1. 添加AppArmor到GRUB裡面，方便Debian在開機時載入AppArmor模組（從Debian 10開始已經預設啓用，因此這個步驟是可以略過的）
    # 寫入輯器編輯grub設定。為了日後維護方便，我們在/etc/default/grub.d/下面建立.cfg文件。（請複製下面斜體命令到終端機上並按下Enter）
    $ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"' \
      | sudo tee /etc/default/grub.d/apparmor.cfg

    # 更新GRUB
    $ sudo update-grub

    #重新啓動電腦
    $ sudo reboot 
  2. 檢測當前AppArmor的狀態。complain mode是只會監控這個處理程序的行為，而enforce mode會嚴格限制處理程序的訪問行為。
    #應該出現Y
    $ cat /sys/module/apparmor/parameters/enabled

    #會有一堆密密麻麻的路徑和程序，可以看到有的是complain模式或是enforce模式
    $ sudo aa-status

    #要是輸出「Yes」表示有正常啓動
    $ sudo aa-enabled

    #倘若你要關掉AppArmor，可以透過拒絕載入所有設定檔的方式關掉
    $ sudo aa-teardown 
  3. 針對Debian/Ubuntu系列，我們可以安裝額外的設定檔。不同程式理論上要有對應的設定檔，但不是每個開發者都會為自己的程式寫一份AppArmor的設定檔，此時我們可以安裝發行版提供的已經配置好的設定檔。這裡有一個建議是，APT安裝的軟體應該是儘量要是官方倉庫的，一來是官方倉庫的套件理論上是比較安全的（the Debian Way），二來是這些設定檔對於官方倉庫的套件的相容性問題基本上會比較小。若你是用Flatpak，那我推薦使用Flatseal來管理應用程式的權限，Snap的用戶可能得要自己去研究一下Interface上的Slot和Plug（這裡我推薦可以看Ivon大大的〈Linux系統的Snap是什麼？跨發行版軟體套件管理員使用方法〉來初步認識到Snap的權限管理）

    #安裝下列兩個設定檔
    $ sudo apt install apparmor-profiles-extra apparmor-profiles 
  4. 而安裝的設定檔會出現在/usr/share/apparmor/extra-profiles/，你可以用「ls /usr/share/apparmor/extra-profiles/」查看下面有哪些社群設定的設定檔。值得一提的是，第2.步安裝的部分設定檔是裝在/usr/share/apparmor/extra-profiles/並且預設是不使用的（其他的基本是在/etc/apparmor.d/下面），若需要啓用，則需要把/usr/share/apparmor/extra-profiles下面的設定檔複製到/etc/apparmor.d/才會啓用（請看第4.步）。
    點擊目標套件，我是用Trixie

    點擊「檔案列表」，可以查看具體會安裝的設定檔，以及社群提供哪些設定檔。
     
  5. # 顯示已經安裝的其他設定檔
    $ ls /usr/share/apparmor/extra-profiles/

    # 安裝設定檔
    $ sudo cp /usr/share/apparmor/extra-profiles/usr.bin.example /etc/apparmor.d/

    # 設為complain mode。若要設為enforce mode，則可以用aa-enforce
    $ sudo aa-complain /etc/apparmor.d/usr.bin.example 
  6. 關於設定檔，值得一提的是，裡面的firefox是Canonical貢獻的，是2011年左右的設定檔，因此不建議直接複製到/etc/apparmor.d/下面使用。 實際上，因為瀏覽器的特殊性，AppArmor和SELinux一般是不會去限制（但會監控）瀏覽器的存取路徑，其中一個原因是瀏覽器在下載文件需要有足夠大的權限去讀取使用者的電腦路徑（基本上就是所有家目錄），因此你就算允許了也和處於complain mode沒兩樣。
  7. 到目前為止，我們完成了最基本的核心配置。 

進一步操作 

　　首先，我們安裝auditd來負責記錄AppArmor的安全事件。要看留意的是，雖然這個套件是可以不安裝的，AppArmor的安全性事件就會和系統日誌記錄在一起，但因為Linux內核會限制事件日誌的寫入頻率，因此你可能需要解出寫入頻率限制（請參考AppArmor官方文件〈Configure AppArmor and fix a denial——Configure notifications for your system〉），而我這裡省麻煩，故直接安裝auditd。（$表示這一行是指令，同樣地，只要複製斜線文字的指令就好了） 

  1. 安裝auditd，建議再裝上audispd-plugins來方便分類、篩選、讀取安全日誌
    $ sudo apt install auditd audispd-plugins 
  2. 啓動相關服務，可以將下列命令的start換成stop（停止相關服務）、status（查看狀態）、reload（可以在對auditd做出變更後，重新載入設定檔）、restart（重新啓動相關服務）
    $ sudo systemctl start auditd 
  3. 查看當前狀態（-s，show），-l（list）顯示所有規則、-D（移除所有規則）。（想看更多，請參考：G. T. Wang的〈Adultd：Linux 系統稽核工具使用教學與範例〉）

    裡面比較值得一提的是PID，PID是process identifier的縮寫，這是用來為每一個處理程序分發一個獨一無二的編號，這個號碼的指派方式依照不同的操作系統有不同的規則，在Linux上（也是最古早、單純的做法）是類似流水線，這個PID編號象徵著處理程序先後執行順序，一般來說，數字愈小愈早被執行，而最近沸沸揚揚的init——systemd，要負責在最前面來初始化系統，因此systemd的PID就是1；而run0是功能類似sudo的一個包含於systemd的一個功能，在獲得使用者同意後，請PID=1的程序分叉出一個進程來執行命令（因為systemd的PID=1），有趣的是，run0不能用來重啓電腦等操作（但是sudo、doas可以），你應該用systemctl reboot來重啓。

    $ sudo auditctl -s

    #可以得到下列輸出
    ***
    enabled 1
    failure 1
    pid 248267
    rate_limit 0
    backlog_limit 8192
    lost 0
    backlog 0
    backlog_wait_time 60000
    backlog_wait_time_actual 0
    loginuid_immutable 0 unlocked
    *** 

　　接著，我們可以來讓apparmor彈出通知，通知我們那個程序被封鎖了什麼路徑的訪問。要留意的是，Debian的apparmor-notify（aa-notify）的版本是4.X的，因此新特性是用不了的（至少得要5.X，這個版本目前只有Sid分支有提供），我就不使用新特性了。我這裡就用Google Chrome來進行實戰（反正我的主力是Firefox，搞壞了也沒差），挑戰看看chrome可否在enforce mode下面讀取最少的路徑。 

  1. 安裝Chrome瀏覽，這部分我就不教了（請參考Ivon大大的〈Linux系統安裝Google Chrome瀏覽器的方法〉），我是直接去Chrome官網下載.deb套件再用終端機安裝的。 
  2. 先讓Chrome處於complain看看，並且使用chrome一段時間
    $ sudo aa-complain /etc/apparmor.d/chrome 
  3. 使用aa-status看看現在狀態
    $ sudo aa-status 
  4. 使用aa-logprof來針對這個瀏覽器進行權限授予，按下對應的英文按鍵就好了
    sys_ptrace是一個syscall，用來讓某一程序可以執行、監控其他的執行程序。Severity的數字愈大，嚴重性愈大，理論上是可信任的程序且這個處理程序有這個需要，我們會放行，因此按「A」
    Chrome的下載服務，這個會用到，也是允許。
    這部分也是關於家目錄的設定檔的存放和讀取，我是選G。可以注意的是，r是指讀取、w是指寫入
    一般是選「A」，同意，對應的使用者讀取對應家目錄路徑下的暫存檔（僅套用中括號1的設定[1 - owner /home/*/.config/google-chrome/Default/Favicons-journal r,]），「O」比較不建議，因為這允許別的使用者下的Chrome去讀取另一個使用者的目錄下的暫存檔。你要是比較懶，也可以選「G」，讓這類情況自動套用，我就選「G」

    後面基本都是這樣的互動式問答，若不確定，我推薦可以請AI（我是用Gemini）來協助理解這些選項的用意，在此我就不一一展示了。至於關於選項的意義，請參考Arch Wiki的說明：aa-logprof。

    若一路設定完成，可以按S來保存。
    若確定寫好設定檔，可以使用
    $ sudo aa-enforce /etc/apparmor.d/chrome 
  5. 值得留意的是，你應該現在complain mode下面進行常規操作，就例如試著瀏覽網頁、下載文件之類的，儘可能讓AppArmor收集到這個軟體所使用到的規則，這樣子且到enforce模式才不會出現功能缺損的問題。同樣地，要是出現問題，可以先切換到complain模式進行行為監控，再執行aa-status接著執行aa-logprof，進行規則的寫入，再切換到enforce模式。針對瀏覽器，我會先推薦在complain模式下使用一週以上，確保日常操作會用到的路徑都被偵測到，在開始規則的寫入。 

點評和我的碎碎唸 

　　AppArmor我一開始還覺得快要涼掉了，因為在很早期Canonical還會為Firefox撰寫AppArmor的配置文件、Debian還會撰寫Chromium的配置文件，但這些配置文件一個已經15年沒更新了、後者已經5年沒更新了（都被放生在/usr/share/apparmor/extra-profiles/裡面），但是這些軟體都還是有在更新，很顯然也不保證可以完美的適配這些軟體。而且，我還發現因為瀏覽器需要使用的路徑太多、接管了也會出現一些問題，很多發行版基本都放行這些瀏覽器（AppArmor、SELinux都不限制瀏覽器），這或許是為何有人會很強調瀏覽器的沙箱功能要完善吧。 

　　但是我又看見AppArmor的希望。我們本來想要來寫關於怎麽看懂裡面的配置文件，甚至手寫一個配置文件，但我覺得這會使得這篇文章的篇幅太大，而且我寫這些內容倒不如去幫忙翻譯那些說明文件，或許還比較省力，而且我說實在也沒動力自己去手寫一個設定檔（我覺得那是開發者的事情，身為終端用戶，我不覺得我需要去偵查你使用的所有路徑），我才親身體會到AppArmor的友善之處，就是aa-logprof，可以讓AppArmor抓取這些程式用到的路徑，你手動逐一添加規則（若不滿意也可以參考官方手冊手動寫一個）。我目前看了下鳥哥的私房菜，SELinux似乎沒有這麼友善的功能，並經二者的本質上是不一樣的，AppArmor是追蹤引用的路徑，我們可以透過限制路徑的讀寫權限來完成安全管理。 

　　但我想到一個問題，以在Debian上的AppArmor來說，實際上AppArmor接管的程式並不多誒！有些是有配置文件，但目的只是不要被標示為unconfined，像是Firefox有配置文件，但AppArmor說這是一個「目前有 0 個程序處於 unconfined（未接管）狀態，但系統中確實有幫它們定義好設定檔。（原文：No. processes are unconfined but have a profile defined.）」。在接管的程式不多的情況下，Linux怎麼會安全？我覺得主要是得益於Linux 原生極其嚴格的傳統 DAC 權限管理，畢竟要執行惡意程式也是需要權限的，如果權限不足，也很難執行惡意程式，但這使得授權工具（例如sudo）要背負重大的漏洞安全把關（還是要學doas那樣，減少功能、減少暴露的漏洞），這或許也解釋了為何Canonical要用Rust寫一個sudo-rs、拋棄Debian上的sudo。同時，我也覺得大家怎麽在走彎路？有些人認為最簡單的方式就是用容器把這些程式關在裡面，權限管理就交給容器來處理（像是交給Snap的Interface），這樣不也就萬無一失，但我覺得這把問題的解決方式複雜化了，寫個配置文件就完事，容器留給版本隔離我覺得還比較好（或是更進階的權限管理，就例如網路連線和端口限制），而且，不少人因為容器限制了一些功能的取用而不小心把容器的權限給得很大，這也有些本末倒置，甚至也有些人為了不要容器隔離環境的限制而選擇使用原生套件管理器安裝套件，就只是因為原生的安全模組部分被架空，讓大家這麼認為、這麼放縱。其實安全和方便本身就是一種權衡，這就看各位是怎麼選，感謝大家看完我的碎碎唸。 

參考資料（訪問日期：2026/04/06~2026/06/06，YYYY/DD/MM） 

於
標籤： , ,

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)
  • 我的RSS閱讀器與推薦插件
    序：我之前有看到有人分享關於RSS閱讀器的使用分享（大概是去年的時候），我發現這個工具還不錯用，因為我個人有瀏覽部落格、新聞之類的習慣，簡言之我還會依賴閱讀文字來獲取知識（至少我可以方便且較為準確地判斷這個內容是否適合我、達到我渴望欲知的資訊）。因為這些文字大多不會在同一個平臺，...
  • 我的Disto-hopping之旅
    我記得之期我有發過兩篇類似的文章，有興趣可以去看一下。   Linux發行版使用心得   GNOME是如何把我踢到KDE桌面 　　我的distro-hopping似乎也快要進入了尾聲，也剛好再半個多月就要開學了，我似乎也要開始著手把之前要累積的一點點題材給講完。那你，準備好了嗎？...
  • LibreOffice 使用技巧大集合
    序：到了大學，我相信有很多做報告的機會，我基於踩了幾次雷，加上我是個在電腦使用方面有些背骨的人，身邊的人都用WIndows、MacOS，而我就算有WIndows我還是用Linux（目前是Ubuntu，這個發行版還不錯用）。其中，用LibreOffice的人少之又少，所以我想分享我...