SLES12 ntpd i apparmor

SLES 12 ntpd i apparmor

O tym co się dzieje, gdy strażnik służbista otrzyma niedokładną instrukcję.

Zadanie

Skonfigurować „coś” na nowym SLES12 w istniejącym środowisku.

Środowisko

Jakieś inne serwery.

Procedura

Dla poprawnego działania jakiejkolwiek usługi serwera, musimy mieć pewność, że czas tego serwera nie odbiega od czasu innych maszyn w sieci. Jeżeli pojawi się jakiś problem trudny do powiązania z tym tylko serwerem, sprawa synchronizacji czasu okaże się kluczowa.

Jeżeli nie możemy ufać stemplom czasowym systemu plików czy logów, to nie możemy skorelować zdarzeń na tym serwerze z innymi zdarzeniami w sieci. Niemożliwe będzie określenie następstwa czasowego czy równoległości zdarzeń w sieci.

Dlatego i z paru innych powodów czas serwera i jego synchronizacja ma kluczowe znaczenie dla administratora. Najczęściej do synchronizacji czasu wykorzystywany jest protokół NTP (Network Time Protocol). Programem używajacym tego protokołu jest demon ntpd korzystający z pliku konfiguracyjnego /etc/ntp.conf.

Konfiguracja w Yast jest prosta:	Alternatywna konfiguracja ntp
dodanie serwerawpisanie adresu serwera lub wybór serwera publicznego z listyzaznaczenie, że demon ma się uruchamiać automatycznie	– dopisanie do pliku ntp.conf linii: server adres_lub_nazwa_serwera_czasu iburst- włączenie automatycznego uruchamiania przy starcie systemctl enable ntpd.service- uruchomienie demona systemctl start ntpd.service

Okazuje się jednak, że pojawia się problem z uruchomieniem demona.

Problem

Systemctl potrafi zawisnąć na kilka minut, po czym oznajmia że nie uruchomił ntpd.

sles12:~ # systemctl start ntpd.serviceJob for ntpd.service failed. See “systemctl status ntpd.service” and “journalctl -xn” for details.

Sprawdzenie stanu usługi może być trochę mylące:

sles12:~ # systemctl status ntpd.servicentpd.service – NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled) Active: activating (auto-restart) (Result: timeout) since śro 2015-03-25 12:51:51 CET; 1min 22s ago Docs: man:ntpd(1) Process: 1764 ExecStart=/usr/sbin/start-ntpd start (code=exited, status=0/SUCCESS)

Trzeba zwrócić uwagę na wynik działania systemd zaraz za słowem Active:

Stan usługi jest określony jako activating (auto-restart) (Result: timeout)

Rzut oka na definicję usługi w /usr/lib/systemd/ntpd.service

sles12:~ # cat /usr/lib/systemd/system/ntpd.service[Unit] Description=NTP Server Daemon Documentation=man:ntpd(1) After=nss-lookup.targetWants=network.target After=network.target[Service] Type=forking PIDFile=/var/run/ntp/ntpd.pid ExecStart=/usr/sbin/start-ntpd start RestartSec=11min Restart=always[Install] WantedBy=multi-user.target

W razie problemów systemd restartuje ntpd co 11 minut do skutku. W razie przypadkowego wyłączenia demona będzie to skuteczne. W naszym przypadku nie pomoże. Systemd będzie restartował demona co 11 minut, ale nie wpłynie to na jego działanie. Musimy szukać dalej.

sles12:~ # journalctl -xn-- Logs begin at śro 2015-03-25 12:37:35 CET, end at śro 2015-03-25 12:51:51 CET. — mar 25 12:50:21 sles12 ntpd[1778]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 mar 25 12:50:21 sles12 ntpd[1778]: Listen and drop on 1 v6wildcard :: UDP 123 mar 25 12:50:21 sles12 ntpd[1778]: Listen normally on 2 lo 127.0.0.1 UDP 123 mar 25 12:50:21 sles12 ntpd[1778]: Listen normally on 3 eth0 192.168.5.72 UDP 123 mar 25 12:50:21 sles12 ntpd[1778]: Listen normally on 4 eth0 192.168.3.72 UDP 123 mar 25 12:50:21 sles12 ntpd[1778]: peers refreshed mar 25 12:50:21 sles12 ntpd[1778]: Listening on routing socket on fd #21 for interface updates mar 25 12:50:21 sles12 kernel: type=1400 audit(1427284221.355:44): apparmor=”DENIED” operation=”mknod” parent=1 mar 25 12:50:47 sles12 kernel: type=1400 audit(1427284247.355:45): apparmor=”DENIED” operation=”file_mmap” paren mar 25 12:51:51 sles12 systemd[1]: Failed to start NTP Server Daemon. — Subject: Unit ntpd.service has failed — Defined-By: systemd — Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel — — Unit ntpd.service has failed. — — The result is failed. lines 1-18/18 (END)

Journalctl pokazuje przyczynę problemu. W logu pojawiają się 2 linie z tekstem apparmor=”DENIED”. Widać, że demon zaczyna działać, zaczyna słuchać na interfejsach lo i eth0. Później chce wykonać 2 operacje na które nie zgadza się apparmor – skutek znamy. Naprawa polega na zmodyfikowaniu profilu apparmor dla programu ntpd. Najwygodniej zrobic to programem logprof, który zanalizuje log i zaproponuje zmiany w profilu.

sles12:~ # logprofReading log entries from /var/log/messages. Updating AppArmor profiles in /etc/apparmor.d. Enforce-mode changes:Profile: /usr/sbin/ntpd Path: /run/nscd/group Mode: r Severity: unknown[1 – /run/nscd/group] (A)llow / [(D)eny] / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)ptsAdding /run/nscd/group r to profile.Profile: /usr/sbin/ntpd Path: /var/lib/ntp/var/run/ntp/ntpd.pid Mode: w Severity: unknown[1 – /var/lib/ntp/var/run/ntp/ntpd.pid] (A)llow / [(D)eny] / (G)lob / Glob w/(E)xt / (N)ew / Abo(r)t / (F)inish / (O)ptsAdding /var/lib/ntp/var/run/ntp/ntpd.pid w to profile. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 – /usr/sbin/ntpd] (S)ave Changes / [(V)iew Changes] / Abo(r)tWriting updated profile for /usr/sbin/ntpd.

Przy korzystaniu z tego programu trzeba zachować ostrożność i zgadzać się wyłącznie na takie zmiany, które są niezbędne dla naszego programu. Może się zdarzyć, że na naszym serwerze pojawi się złośliwy program, a my radośnie pozwolimy mu na swobodne działanie. W naszym przypadku ntpd chce odczytywać dane programu nscd I zapisywać swój PID w pliku. Możemy się zgodzić na proponowane zmiany. Po zapisaniu zmian możemy uruchomić usługę.

sles12:~ # systemctl restart ntpd.servicesles12:~ # systemctl status ntpd.servicentpd.service – NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled) Active: active (running) since śro 2015-03-25 12:57:46 CET; 4s ago Docs: man:ntpd(1) Process: 1831 ExecStart=/usr/sbin/start-ntpd start (code=exited, status=0/SUCCESS) Main PID: 1843 (ntpd) CGroup: /system.slice/ntpd.service └─1843 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.confmar 25 12:57:46 sles12 start-ntpd[1831]: Starting network time protocol daemon (NTPD) mar 25 12:57:46 sles12 ntpd[1843]: proto: precision = 0.168 usec mar 25 12:57:46 sles12 ntpd[1843]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 mar 25 12:57:46 sles12 ntpd[1843]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 mar 25 12:57:46 sles12 ntpd[1843]: Listen and drop on 1 v6wildcard :: UDP 123 mar 25 12:57:46 sles12 ntpd[1843]: Listen normally on 2 lo 127.0.0.1 UDP 123 mar 25 12:57:46 sles12 ntpd[1843]: Listen normally on 3 eth0 192.168.5.72 UDP 123 mar 25 12:57:46 sles12 ntpd[1843]: Listen normally on 4 eth0 192.168.3.72 UDP 123 mar 25 12:57:46 sles12 ntpd[1843]: peers refreshed mar 25 12:57:46 sles12 ntpd[1843]: Listening on routing socket on fd #21 for interface updatessles12:~ #

Tym razem wszystko działa tak jak tego oczekiwaliśmy.

Apparmor jest programem zabezpieczajacym komputer przed nieprawidłowym działaniem innych programów. Dla kazdego chronionego programu zdefiniowany jest profil w którym zapisano co ten program może robić. Określa się jakie pliki czy kartoteki mogą być odczytywane i gdzie program może tworzyc swoje pliki. Każda próba działania poza zapisanymi w profilu jest blokowana. Apparmor jest domyślnie włączany w SLES12.