W zeszłym tygodniu omawialiśmy, jak skonfigurować AppArmor dla zestawów replik MongoDB, które zasadniczo mają te same koncepcje, które można zastosować podczas konfigurowania tego dla systemów opartych na MySQL. Rzeczywiście, bezpieczeństwo jest bardzo ważne, ponieważ musisz upewnić się, że Twoje dane są bardzo dobrze chronione i zabezpieczone przed niepożądanym gromadzeniem informacji z domeny biznesowej.
Trochę historii o AppArmor
AppArmor został po raz pierwszy użyty w systemie Immunix Linux 1998–2003. W tamtym czasie AppArmor był znany jako SubDomain, co odnosiło się do możliwości segmentacji profilu bezpieczeństwa dla określonego programu na różne domeny, między którymi program może się przełączać dynamicznie. AppArmor został po raz pierwszy udostępniony w SLES i openSUSE, a po raz pierwszy został włączony domyślnie w SLES 10 i openSUSE 10.1.
W maju 2005 Novell nabył Immunix i zmienił nazwę SubDomain na AppArmor oraz rozpoczął czyszczenie kodu i przepisywanie go w celu włączenia do jądra Linux. Od 2005 r. do września 2007 r. AppArmor był utrzymywany przez firmę Novell. Firma Novell została przejęta przez firmę SUSE, która jest teraz prawnym właścicielem znaku towarowego AppArmor.
AppArmor został po raz pierwszy pomyślnie przeniesiony/spakowany dla Ubuntu w kwietniu 2007. AppArmor stał się domyślnym pakietem począwszy od Ubuntu 7.10 i pojawił się jako część wydania Ubuntu 8.04, chroniąc domyślnie tylko CUPS. Od Ubuntu 9.04 więcej elementów, takich jak MySQL, ma zainstalowane profile. Utwardzanie AppArmor nadal się poprawiało w Ubuntu 9.10, ponieważ jest ono dostarczane z profilami sesji gościa, maszynami wirtualnymi libvirt, przeglądarką dokumentów Evince i opcjonalnym profilem Firefox.
Dlaczego potrzebujemy AppArmor?
W naszym poprzednim blogu zajęliśmy się trochę tym, do czego służy AppArmor. Jest to system obowiązkowej kontroli dostępu (MAC), zaimplementowany w modułach zabezpieczeń systemu Linux (LSM). Jest używany i najczęściej domyślnie włączony w systemach takich jak Ubuntu, Debian (od Bustera), SUSE i innych dystrybucjach. Jest porównywalny z RHEL/CentOS SELinux, który do poprawnego działania wymaga dobrej integracji z przestrzenią użytkownika. SELinux dołącza etykiety do wszystkich plików, procesów i obiektów, dzięki czemu jest bardzo elastyczny. Jednak konfiguracja SELinuksa jest uważana za bardzo skomplikowaną i wymaga obsługiwanego systemu plików. Z drugiej strony AppArmor działa przy użyciu ścieżek plików, a jego konfigurację można łatwo dostosować.
AppArmor, podobnie jak większość innych LSM, uzupełnia, a nie zastępuje domyślną dyskretną kontrolę dostępu (DAC). W związku z tym niemożliwe jest nadanie procesowi większej liczby uprawnień niż miał.
AppArmor proaktywnie chroni system operacyjny i aplikacje przed zagrożeniami zewnętrznymi lub wewnętrznymi, a nawet atakami typu zero-day, wymuszając określone reguły dla poszczególnych aplikacji. Zasady bezpieczeństwa całkowicie definiują, do jakich zasobów systemowych mogą mieć dostęp poszczególne aplikacje i jakie uprawnienia. Dostęp jest domyślnie odmawiany, jeśli żaden profil nie mówi inaczej. Do AppArmor dołączono kilka domyślnych zasad, a dzięki połączeniu zaawansowanej analizy statycznej i narzędzi opartych na uczeniu, zasady AppArmor dla nawet bardzo złożonych aplikacji można pomyślnie wdrożyć w ciągu kilku godzin.
Każde naruszenie zasad powoduje wyświetlenie komunikatu w dzienniku systemowym, a AppArmor można skonfigurować tak, aby powiadamiał użytkowników o naruszeniu w czasie rzeczywistym.
AppArmor dla MySQL
Skonfigurowałem klaster oparty na replikacji MySQL przy użyciu ClusterControl do węzłów docelowej bazy danych działających w systemie Ubuntu Bionic. Możesz dalej śledzić ten blog, aby dowiedzieć się, jak go wdrożyć, lub skorzystać z tego samouczka wideo. Zwróć uwagę, że ClusterControl sprawdza lub wyłącza AppArmor podczas wdrażania. Być może będziesz musiał odznaczyć to zgodnie z twoją konfiguracją, tak jak poniżej:
ClusterControl po prostu wyśle ostrzeżenie, że nie dotyka bieżącej konfiguracji AppArmor . Zobacz poniżej:
Zarządzanie profilami AppArmor
Standardowa instalacja AppArmor w Ubuntu nie zawierałaby narzędzi, które pomogłyby w efektywnym zarządzaniu profilami. Zainstalujmy więc te pakiety w następujący sposób:
$ apt install apparmor-profiles apparmor-utilsPo zainstalowaniu sprawdź stan swojego AppArmor w systemie, uruchamiając polecenie aa-status. W węźle, którego używam, mam następujące dane wyjściowe bez zainstalowanego MySQL 8.
$ aa-status
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
/sbin/dhclient
/usr/bin/lxc-start
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/sbin/tcpdump
lxc-container-default
lxc-container-default-cgns
lxc-container-default-with-mounting
lxc-container-default-with-nesting
man_filter
man_groff
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.Ponieważ używam ClusterControl do wdrażania mojego klastra opartego na replikacji MySQL za pomocą AppArmor (tj. ClusterControl nie dotknie mojej obecnej konfiguracji AppArmor), wdrożenie powinno mieć profil MySQL, który pojawi się w lista działa ze statusem aa.
$ aa-status
apparmor module is loaded.
56 profiles are loaded.
19 profiles are in enforce mode.
...
/usr/sbin/mysqld
...
37 profiles are in complain mode.
...
1 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/mysqld (31501)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Warto zauważyć, że profil znajduje się w jednym z następujących trybów:
-
Wymuś — ustawienie domyślne. Aplikacje nie mogą podejmować działań ograniczonych przez zasady profilu.
-
Narzekaj — aplikacje mogą podejmować ograniczone działania, które są rejestrowane.
-
Wyłączone — aplikacje mogą wykonywać ograniczone działania, które nie są rejestrowane.
Możesz także mieszać profile egzekwowania i skarg na swoim serwerze.
Na podstawie powyższych danych wyjściowych omówimy dokładniej skargę dotyczącą profilu. AppArmor pozwoli mu wykonać (prawie tak, jak stan trybu skargi nadal będzie wymuszał wyraźne reguły odmowy w profilu) wszystkich zadań bez ograniczeń, ale zarejestruje je w dzienniku audytu jako zdarzenia. Jest to przydatne, gdy próbujesz utworzyć profil dla aplikacji, ale nie masz pewności, do czego potrzebuje dostępu. Natomiast stan nieograniczony pozwoli programowi na wykonanie dowolnego zadania i nie będzie go rejestrować. Zwykle dzieje się tak, jeśli profil został załadowany po uruchomieniu aplikacji, co oznacza, że działa bez ograniczeń z AppArmor. Należy również zauważyć, że tylko procesy, które mają profile, są wymienione w tym statusie nieograniczonym. Wszelkie inne procesy, które działają w Twoim systemie, ale nie mają dla nich utworzonego profilu, nie będą wyświetlane w statusie aa.
Jeśli wyłączyłeś AppArmor, ale zdasz sobie sprawę, że chcesz zwiększyć swoje bezpieczeństwo lub zachować zgodność z przepisami bezpieczeństwa, możesz użyć tego profilu MySQL 8.0, który jest dostarczany przez sam MySQL. Aby to zastosować, po prostu uruchom następujące polecenie:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aWarto zauważyć, że profile AppArmor są domyślnie przechowywane w /etc/apparmor.d/. Dobrą praktyką jest dodawanie profili w tym katalogu.
Diagnozowanie profili AppArmor
Dzienniki AppArmor można znaleźć w dzienniku systemd, w /var/log/syslog i /var/log/kern.log (oraz /var/log/audit.log, gdy zainstalowany jest auditd). To, czego potrzebujesz, to:
-
DOZWOLONE (rejestrowane, gdy profil w trybie skargi narusza zasady)
-
DENIED (rejestrowane, gdy profil w trybie wymuszania faktycznie blokuje operację)
Pełny komunikat dziennika powinien zawierać więcej informacji o tym, jaki dokładnie dostęp został odmówiony. Możesz użyć tego do edycji profili przed włączeniem ich w trybie wymuszania.
Na przykład
$ grep -i -rn -E 'apparmor=.*denied|apparmor=.*allowed' /var/log/
/var/log/kern.log:503:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"
Binary file /var/log/journal/877861ee473c4c03ac1512ed369dead1/system.journal matches
/var/log/syslog:1012:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"Dostosowywanie profilu AppArmor
Profile przygotowane przez Oracle MySQL nie mogą być wzorcem uniwersalnym. W takim przypadku możesz na przykład zmienić katalog danych, w którym znajdują się dane instancji MySQL. Po zastosowaniu zmian w pliku konfiguracyjnym i ponownym uruchomieniu instancji MySQL, AppArmor odmówi tej akcji. Na przykład
$ egrep -i -rn 'apparmor=.*denied|apparmor=.*allowed' /var/log/
/var/log/kern.log:503:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"
/var/log/kern.log:522:Jun 18 19:46:26 ubuntu-bionic kernel: [ 3801.151770] audit: type=1400 audit(1624045586.822:67): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5262 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002
Binary file /var/log/journal/877861ee473c4c03ac1512ed369dead1/system.journal matches
/var/log/syslog:1012:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"
/var/log/syslog:1313:Jun 18 19:46:26 ubuntu-bionic kernel: [ 3801.151770] audit: type=1400 audit(1624045586.822:67): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5262 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002Wraz z błędem, który miałem wcześniej, teraz dodaje, że właśnie zdecydowałem się użyć katalogu /mysql-data, ale jest to odrzucone.
Aby zastosować zmiany, wykonajmy następujące czynności. Edytuj plik /etc/apparmor.d/usr.sbin.mysqld. Możesz znaleźć te wiersze:
# Allow data dir access
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
Those flags such as r, rwk are the so-called access modes. These mean the following:
r - read
w - write -- conflicts with append
k - lock
Strona podręcznika wyjaśnia te flagi bardziej szczegółowo.
Teraz zmieniłem to na następujące:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Następnie ponownie ładuję profile w następujący sposób:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldZrestartuj serwer MySQL:
$ systemctl restart mysql.serviceCo jeśli ustawię mysqld na tryb reklamacji?
Jak wspomniano wcześniej, stan trybu skargi nadal będzie wymuszał w profilu wszelkie wyraźne reguły odmowy. Chociaż działa to na przykład:
$ aa-complain /usr/sbin/mysqldUstawianie /usr/sbin/mysqld na tryb reklamacji.
W takim razie
$ aa-status
apparmor module is loaded.
56 profiles are loaded.
18 profiles are in enforce mode.
...
38 profiles are in complain mode.
...
1 processes have profiles defined.
0 processes are in enforce mode.
1 processes are in complain mode.
/usr/sbin/mysqld (23477)
0 processes are unconfined but have a profile defined.Po ponownym uruchomieniu MySQL uruchomi się i wyświetli pliki dziennika, takie jak:
/var/log/syslog:1356:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.427074] audit: type=1400 audit(1624046331.098:83): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5760 comm="mysqld" requested_mask="wrc" denied_mask="wrc" fsuid=1002 ouid=1002
/var/log/syslog:1357:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.432077] audit: type=1400 audit(1624046331.102:84): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock" pid=5760 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002
/var/log/syslog:1358:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.432101] audit: type=1400 audit(1624046331.102:85): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.pid" pid=5760 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002
And it will work. However, it will probably have issues with networking as it still denies entries as what we have in /etc/apparmor.d/usr.sbin.mysqld. For example, my replica is not able to connect to the primary:
Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 10 retries: 1 message: Host '192.168.40.247' is not allowed to connect to this MySQL server
Last_SQL_Errno: 0W takim przypadku użycie wymuszania i ponownego ładowania profilu powinno być wydajnym i łatwym podejściem do zarządzania profilami MySQL za pomocą AppArmor.
