Forum Debian Users Gang

wiarus · 2023-05-11 10:14:11

Cześć.

Dawno temu utworzyłem profil AppArmor dla systemd-timesyncd (ścieżka /usr/lib/systemd/systemd-timesyncd).
Wszystko zdawało się działać, profil pojawiał się w sekcji 'enforced' polecenia aa-status.

Później, dodałem profil dla systemd-resolved (ścieżka /usr/lib/systemd/systemd-resolved). Podobnie jak wyżej,
nie widziałem problemów. Kiedy, zmieniłem zapis ścieżek w obu profilach na:

/{,usr/}lib/systemd/systemd-timesyncd
/{,usr/}lib/systemd/systemd-resolved

w celu uwzględnienia również ścieżek /lib/systemd/systemd-{timesyncd,resolved}, okazało się, że
np. po zalogowaniu do systemu profile nie pojawiają się w sekcji 'enforced' (wygląda to tak,
jakby w ogóle nie zostały uruchomione). Oczywiście, dostępne są w bloku profili tzn. "X profiles are in enforce mode."

Po powrocie do poprzedniego, domyślnego zapisu, profile pojawiają się, ale tym razem w sekcji:

,----[ aa-status ] 2 processes are unconfined but have a profile defined. /usr/lib/systemd/systemd-resolved (413) /usr/lib/systemd/systemd-timesyncd (414) `----

Dopiero restart obu usług za pomocą polecenia [systemctl restart] sprawia, że pojawiają się
w odpowiednim miejscu: "X processes are in enforce mode."

Spróbowałem usunąć oba profile i utworzyć je na nowo, ale to nie pomogło. Czy ktoś z Was mógłby
pomóc w rozwiązaniu tego problemu? Przecież skoro usługi są ustawione w tryb 'enforce',
to powinny znajdować się w odpowiedniej sekcji polecenia [aa-status].

Dlaczego więc pojawiły się problemy z dwoma wymienionymi profilami?

Dzięki, pozdrawiam.
____________________
P.S. W profilu wpa_supplicant zastosowałem taki zapis: '/{,usr/}sbin/wpa_supplicant' i nie ma
problemu. Za każdym razem profil jest umieszczony w odpowiednim miejscu.

Jacekalex · 2023-05-11 19:31:46

Prawdopodobnie wstały przed wczytaniem profili AA, ustaw Apparmora, aby wstawał w systemd najwcześniej, jak się da, koniecznie przed usługami, które ma chronić.

wiarus · 2023-05-12 15:15:02

Cześć Jacekalex. Możesz nakierować mnie w jaki sposób można to zrobić? Pytam bo np. AppArmor, według logów, startuje
przed systemd-timesyncd (ale w tym przypadku, zdarza się że czas jest zaktualizowany "lokalnie" - "(...) restoring from recorded timestam").

A może rozwiązaniem jest restart usług za pomocą mechanizmu znanego choćby z pliku /etc/rc.local? Albo utworzyć
plik /etc/systemd/system/run-before-login.service, dodać odpowiednie opcje itd. Ale takie rozwiązanie, w pewien sposób,
przeczy posiadaniu profilów AppArmor.

Być może powodem są aktualizacje (np. z kwietnia), które dot. m.in. systemd-timesyncd - ale to tylko luźna myśl.

Pozdro.

Jacekalex · 2023-05-12 20:03:41

Nie mam w tej chwili pod ręką Systemd, w Gentusiowym OpenRC Apparmor wstaje w profilu sysinit w towarzystwie udeva.

Kod:

# root ~> rc-status sysinit
 * Caching service dependencies ...                                       [ ok ]
Runlevel: sysinit
 sysfs                                                             [  started  ]
 devfs                                                             [  started  ]
 kmod-static-nodes                                                 [  started  ]
 udev                                                              [  started  ]
 systemd-tmpfiles-setup-dev                                        [  started  ]
 apparmor                                                          [  started  ]
 dmesg                                                             [  started  ]
 cgroups                                                           [  started  ]
 udev-trigger                                                      [  started  ]

Co do Apparmora i Systemd to raczej Morfik będzie bardziej zorientowany.
;)

Ostatnio edytowany przez Jacekalex (2023-05-12 20:59:53)

morfik · 2023-05-14 08:22:46

Ja tam ładuje profile przed startem systemu: xD

Ostatnio edytowany przez morfik (2023-05-14 08:23:05)

wiarus · 2023-05-27 21:15:48

Cześć.

Sorry chłopaki za zwłokę z odpowiedzią, ale nie miałem czasu. W wolnej chwili przeglądne
stronę podaną przez Ciebie, Morfik.

Na tę chwilę rozwiązałem to w ten sposób: utworzyłem plik /etc/NetworkManager/dispatcher.d/10-timesync-resolved-restart,
dodałem dwa polecenia systemctl restart, oddzielone przez 0.2 sekundy. Wygląda na to, że działa.
Po ponownym zalogowaniu się do systemu, sprawdzając status AppArmor, oba procesy - systemd-timesyncd
i systemd-resolved znajdują się w odpowiednim miejscu.

To rozwiązanie jest jednak jak proteza. Mam nadzieje, że chwilowa.

A może to jest jakiś bug w AppArmor? Co o tym myślicie?

Pozdrawiam.

morfik · 2023-06-06 09:00:41

Gdybyś przeczytał podlinkowany przeze mnie artykuł, to byś znał przyczynę. xD

wiarus · 2023-06-14 22:37:08

Cześć.

Morfik, napisałem wyraźnie, że zrobię to, ale w wolnej chwili... :- )

Pozdrawiam.

Forum Debian Users Gang

Ogłoszenie

#1 2023-05-11 10:14:11

wiarus - Użytkownik

AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

#2 2023-05-11 19:31:46

Jacekalex - Podobno człowiek...;)

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

#3 2023-05-12 15:15:02

wiarus - Użytkownik

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

#4 2023-05-12 20:03:41

Jacekalex - Podobno człowiek...;)

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

Kod:

#5 2023-05-14 08:22:46

morfik - Cenzor wirtualnego świata

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

#6 2023-05-27 21:15:48

wiarus - Użytkownik

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

#7 2023-06-06 09:00:41

morfik - Cenzor wirtualnego świata

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

#8 2023-06-14 22:37:08

wiarus - Użytkownik

Re: AArmor: profile w trybie 'enforced' nie są uwzględniane (aa-status)

Stopka forum