<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Apparmor on Morfitronik</title>
    <link>https://morfikov.github.io/tags/apparmor/</link>
    <description>Recent content in Apparmor on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Mon, 23 Sep 2019 19:05:21 +0200</lastBuildDate><atom:link href="https://morfikov.github.io/tags/apparmor/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak załadować profile AppArmor w fazie initrd/initramfs na Debian Linux</title>
      <link>https://morfikov.github.io/post/jak-zaladowac-profile-apparmor-w-fazie-initrd-initramfs-na-debian-linux/</link>
      <pubDate>Mon, 23 Sep 2019 19:05:21 +0200</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-zaladowac-profile-apparmor-w-fazie-initrd-initramfs-na-debian-linux/</guid>
      <description>&lt;p&gt;Zapewne wielu użytkowników Debiana zdążyło już zauważyć, że od wydania 10 (Buster), AppArmor jest
włączony domyślnie. Nie powinien on raczej sprawiać żadnych problemów po doinstalowaniu pakietów
&lt;code&gt;apparmor-profiles&lt;/code&gt; oraz &lt;code&gt;apparmor-profiles-extra&lt;/code&gt; , które zawierają szereg profili pod różne
aplikacje użytkowe. Niemniej jednak, pewnych procesów nie da się ograniczyć przez AppArmor,
przynajmniej nie w standardowy sposób. Chodzi o to, że jeśli mamy już odpalony jakiś proces, to nie
ma możliwości zamknąć go w profilu AA do momentu aż zakończy on swoje działanie i zostanie
uruchomiony ponownie. Profile AppArmor&#39;a są ładowane podczas startu systemu w pewnym określonym
momencie ale szereg procesów systemowych startuje sporo wcześniej w stosunku do usługi AppArmor&#39;a.
W taki sposób nawet jeśli w późniejszym czasie profile zostaną załadowane, to i tak część procesów
nie będzie ograniczona bez względu na to czy zdefiniowaliśmy im zestaw reguł. Oczywiście można
próbować restartować usługi lub szeregować je po &lt;code&gt;apparmor.service&lt;/code&gt; ale nie zawsze tak się da
zrobić. Alternatywnym rozwiązaniem tego problemu jest ładowanie polityki AppArmor&#39;a w fazie
initrd/initramfs, czyli w momencie, w którym nasz system nie ma jeszcze nawet uruchomionego procesu
z PID z numerkiem &lt;code&gt;1&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Capability dac_read_search i dac_override w profilu AppArmor&#39;a</title>
      <link>https://morfikov.github.io/post/capability-dac_read_search-dac_override-w-profilu-apparmor/</link>
      <pubDate>Mon, 16 Sep 2019 18:20:15 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/capability-dac_read_search-dac_override-w-profilu-apparmor/</guid>
      <description>&lt;p&gt;Od jakiegoś czasu tworzę dla aplikacji w moim Debianie &lt;a href=&#34;https://gitlab.com/morfikov/debian-files/tree/master/configs/etc/apparmor.d&#34;&gt;profile pod AppArmor&lt;/a&gt;, tak by ograniczyć
programom swobodny dostęp do plików czy urządzeń. Tych profili zebrało się już trochę i podczas
pisania jednego z nich, zacząłem się zastanawiać czy wszystkie CAP&#39;y (linux capabilities), których
żądają procesy, są im faktycznie niezbędne do prawidłowego funkcjonowania. Chodzi póki co o
&lt;code&gt;dac_read_search&lt;/code&gt; i &lt;code&gt;dac_override&lt;/code&gt; . Co ciekawe, odmowa &lt;code&gt;dac_override&lt;/code&gt; w części aplikacji nie
powodowała żadnych negatywnych konsekwencji. Idąc dalej tym tropem, postanowiłem z paru profili AA
usunąć linijkę zawierającą &lt;code&gt;capability dac_override,&lt;/code&gt; zostawiając tym samym jedynie
&lt;code&gt;capability dac_read_search,&lt;/code&gt;  i zobaczyć co się stanie. Okazało się, że sporo programów już o
&lt;code&gt;dac_override&lt;/code&gt; nie prosi. Zatem co się zmieniło przez tych parę lat i czy ta zmiana dotyczy samych
aplikacji, a może kernela linux&#39;a?&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Profil AppArmor&#39;a i jego dokładna budowa</title>
      <link>https://morfikov.github.io/post/profil-apparmora-i-jego-dokladna-budowa/</link>
      <pubDate>Tue, 01 Dec 2015 17:57:39 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/profil-apparmora-i-jego-dokladna-budowa/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://morfikov.github.io/post/apparmor-profilowanie-aplikacji/&#34;&gt;Budowanie samych profili dla AppArmor&#39;a&lt;/a&gt;
nie jest jakoś szczególnie trudne, zwłaszcza, gdy do tego celu wykorzystujemy narzędzia dostępne w
pakiecie &lt;code&gt;apparmor-utils&lt;/code&gt; . Dobrze jest jednak prześledzić sobie
&lt;a href=&#34;http://manpages.ubuntu.com/manpages/xenial/en/man5/apparmor.d.5.html&#34;&gt;manual&lt;/a&gt;
&lt;a href=&#34;http://manpages.ubuntu.com/manpages/xenial/en/man7/apparmor.7.html&#34;&gt;AppArmor&#39;a&lt;/a&gt; oraz to, co twórcy
piszą na swojej stronie w &lt;a href=&#34;http://wiki.apparmor.net/index.php/Documentation&#34;&gt;oficjalnej
dokumentacji&lt;/a&gt; projektu. Poniższy wpis powstał w
celu zrozumienia składni profili AppArmor&#39;a, tak by jeszcze bardziej uprościć proces ich budowania.&lt;/p&gt;
&lt;p&gt;Opis składni znajdujący się poniżej został zaczerpnięty z
&lt;a href=&#34;http://wiki.apparmor.net/index.php/QuickProfileLanguage&#34;&gt;wiki&lt;/a&gt;
&lt;a href=&#34;http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference&#34;&gt;AppArmor&#39;a&lt;/a&gt;. Część z poniższych
informacji może nie mieć zastosowania w przypadku starszych wersji samego AppArmor&#39;a.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>AppArmor i profilowanie aplikacji</title>
      <link>https://morfikov.github.io/post/apparmor-profilowanie-aplikacji/</link>
      <pubDate>Sat, 08 Aug 2015 23:33:59 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/apparmor-profilowanie-aplikacji/</guid>
      <description>&lt;p&gt;Po ostatnich doniesieniach na temat &lt;a href=&#34;https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/&#34;&gt;błędu jaki został znaleziony w
Firefox&#39;ie&lt;/a&gt; ,
doszedłem do wniosku, że najwyższy czas nauczyć się obsługi narzędzia &lt;code&gt;AppArmor&lt;/code&gt; . Ma ono pomóc w
kontrolowaniu praw dostępu do zasobów systemu operacyjnego, np. plików, katalogów czy określonych
urządzeń. Jeśli weźmiemy przytoczony wyżej błąd, to przeglądarka bez takiego profilu AppArmor&#39;a była
w stanie przeszukać lokalne pliki i wysłać je gdzieś na net, co powodowałoby udostępnienie poufnych
danych, np. historia poleceń shell&#39;owych, czy klucze prywatne.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
