Cara mengkonfigurasi AppArmor untuk sistem berbasis MySQL (Replikasi MySQL/MariaDB + Galera)

Minggu lalu, kami membahas cara mengonfigurasi AppArmor untuk Kumpulan Replika MongoDB yang pada dasarnya memiliki konsep yang sama yang berlaku saat mengonfigurasi ini untuk sistem berbasis MySQL Anda. Memang, keamanan sangat penting karena Anda harus memastikan bahwa data Anda terlindungi dengan sangat baik dan terbungkus dari pengumpulan informasi yang tidak diinginkan dari domain bisnis Anda.

Sedikit sejarah tentang AppArmor

AppArmor pertama kali digunakan di Immunix Linux 1998–2003. Pada saat itu, AppArmor dikenal sebagai SubDomain, referensi untuk kemampuan profil keamanan untuk program tertentu untuk disegmentasi ke dalam domain yang berbeda, yang dapat dialihkan oleh program secara dinamis. AppArmor pertama kali tersedia di SLES dan openSUSE, dan pertama kali diaktifkan secara default di SLES 10 dan di openSUSE 10.1.

Pada Mei 2005, Novell mengakuisisi Immunix dan mengganti nama SubDomain menjadi AppArmor dan mulai membersihkan dan menulis ulang kode untuk dimasukkan ke dalam kernel Linux. Dari 2005 hingga September 2007, AppArmor dikelola oleh Novell. Novell diambil alih oleh SUSE yang sekarang menjadi pemilik sah dari nama bermerek dagang AppArmor.

AppArmor pertama kali berhasil di-porting/dikemas untuk Ubuntu pada April 2007. AppArmor menjadi paket default yang dimulai di Ubuntu 7.10, dan datang sebagai bagian dari rilis Ubuntu 8.04, hanya melindungi CUPS secara default. Pada Ubuntu 9.04 lebih banyak item seperti MySQL telah menginstal profil. Pengerasan AppArmor terus meningkat di Ubuntu 9.10 karena disertakan dengan profil untuk sesi tamunya, mesin virtual libvirt, penampil dokumen Evince, dan profil Firefox opsional.

Mengapa kita membutuhkan AppArmor?

Di blog kami sebelumnya, kami telah membahas sedikit tentang kegunaan AppArmor. Ini adalah sistem Kontrol Akses Wajib (MAC), diimplementasikan pada Modul Keamanan Linux (LSM). Ini digunakan dan sebagian besar diaktifkan secara default di sistem seperti Ubuntu, Debian (sejak Buster), SUSE, dan distribusi lainnya. Ini sebanding dengan RHEL/CentOS SELinux, yang membutuhkan integrasi ruang pengguna yang baik agar berfungsi dengan baik. SELinux menempelkan label ke semua file, proses, dan objek dan karenanya sangat fleksibel. Namun, mengkonfigurasi SELinux dianggap sangat rumit dan membutuhkan sistem file yang didukung. AppArmor, di sisi lain, bekerja menggunakan jalur file dan konfigurasinya dapat dengan mudah disesuaikan.

AppArmor, seperti kebanyakan LSM lainnya, melengkapi daripada menggantikan Kontrol Akses Diskresi (DAC) default. Karena itu, tidak mungkin untuk memberikan proses lebih banyak hak istimewa daripada yang telah diberikan sebelumnya.

AppArmor secara proaktif melindungi sistem operasi dan aplikasi dari ancaman eksternal atau internal dan bahkan serangan zero-day dengan menerapkan aturan khusus yang ditetapkan pada basis per aplikasi. Kebijakan keamanan sepenuhnya menentukan sumber daya sistem apa yang dapat diakses oleh aplikasi individu, dan dengan hak istimewa apa. Akses ditolak secara default jika tidak ada profil yang mengatakan sebaliknya. Beberapa kebijakan default disertakan dengan AppArmor dan menggunakan kombinasi analisis statis lanjutan dan alat berbasis pembelajaran, kebijakan AppArmor bahkan untuk aplikasi yang sangat kompleks dapat diterapkan dengan sukses dalam hitungan jam.

Setiap pelanggaran kebijakan memicu pesan di log sistem, dan AppArmor dapat dikonfigurasi untuk memberi tahu pengguna dengan peringatan pelanggaran waktu nyata.

AppArmor untuk MySQL

Saya telah menyiapkan cluster berbasis replikasi MySQL menggunakan ClusterControl ke node database target saya yang berjalan di Ubuntu Bionic. Anda dapat mengikuti blog ini lebih lanjut tentang cara menyebarkannya atau mengikuti tutorial video ini. Perhatikan bahwa ClusterControl memeriksa atau menonaktifkan AppArmor selama penerapan. Anda mungkin harus menghapus centang ini sesuai dengan pengaturan Anda seperti di bawah ini:

ClusterControl hanya akan mengeluarkan peringatan bahwa itu tidak menyentuh konfigurasi AppArmor Anda saat ini . Lihat di bawah:

Mengelola profil AppArmor Anda

Instalasi standar AppArmor Anda di Ubuntu tidak akan menyertakan utilitas yang akan membantu mengelola profil secara efisien. Jadi mari kita instal paket-paket ini seperti ini:

$ apt install apparmor-profiles apparmor-utils

Setelah diinstal, periksa status AppArmor Anda di sistem dengan menjalankan perintah aa-status. Di node yang saya gunakan, saya memiliki output berikut tanpa menginstal 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.

Karena saya menggunakan ClusterControl untuk menerapkan cluster berbasis replikasi MySQL dengan AppArmor (yaitu ClusterControl tidak akan menyentuh konfigurasi AppArmor saya saat ini), penerapan harus memiliki profil MySQL dan yang muncul di daftar menjalankan aa-status.

$ 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.

Perlu dicatat bahwa profil berada dalam salah satu mode berikut:

Terapkan - Pengaturan default. Aplikasi dicegah mengambil tindakan yang dibatasi oleh aturan profil.
Keluhan - Aplikasi diizinkan untuk melakukan tindakan terbatas, dan tindakan tersebut dicatat.
Dinonaktifkan - Aplikasi diizinkan untuk melakukan tindakan yang dibatasi, dan tindakan tersebut tidak dicatat.

Anda juga dapat menggabungkan profil penegakan dan keluhan di server Anda.

Berdasarkan output di atas, mari kita uraikan lebih lanjut tentang profil keluhan. AppArmor akan mengizinkannya untuk melakukan (hampir seperti status mode keluhan akan tetap menerapkan aturan penolakan eksplisit dalam profil) semua tugas tanpa batasan tetapi akan mencatatnya di log audit sebagai peristiwa. Ini berguna ketika Anda mencoba membuat profil untuk suatu aplikasi tetapi tidak yakin hal-hal apa yang perlu diaksesnya. Sedangkan status tidak terbatas, di sisi lain, akan memungkinkan program untuk melakukan tugas apa pun dan tidak akan mencatatnya. Ini biasanya terjadi jika profil dimuat setelah aplikasi dimulai, artinya profil berjalan tanpa batasan dari AppArmor. Penting juga untuk dicatat bahwa hanya proses yang memiliki profil yang terdaftar di bawah status tidak terbatas ini. Proses lain yang berjalan di sistem Anda tetapi tidak memiliki profil yang dibuat untuk proses tersebut tidak akan dicantumkan di bawah status aa.

Jika Anda telah menonaktifkan AppArmor tetapi kemudian menyadari bahwa Anda ingin meningkatkan keamanan Anda atau mematuhi peraturan keamanan, Anda dapat menggunakan profil MySQL 8.0 ini yang disediakan oleh MySQL sendiri. Untuk menerapkannya, jalankan saja perintah berikut:

$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -a

Perlu dicatat bahwa profil AppArmor disimpan secara default di /etc/apparmor.d/. Ini adalah praktik yang baik untuk menambahkan profil Anda di direktori itu.

Mendiagnosis profil AppArmor Anda

Log AppArmor dapat ditemukan di jurnal systemd, di /var/log/syslog dan /var/log/kern.log (dan /var/log/audit.log saat auditd diinstal). Yang perlu Anda cari adalah sebagai berikut:

DIPERBOLEHKAN (dicatat saat profil dalam mode keluhan melanggar kebijakan)
DITOLAK (dicatat saat profil dalam mode penegakan benar-benar memblokir operasi)

Pesan log lengkap harus memberikan informasi lebih lanjut tentang akses persis apa yang telah ditolak. Anda dapat menggunakan ini untuk mengedit profil sebelum mengaktifkannya dalam mode penegakan.

Misalnya,

$ 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"

Menyesuaikan profil AppArmor Anda

Profil yang disiapkan oleh Oracle MySQL tidak boleh berupa pola satu ukuran untuk semua. Dalam hal ini, Anda mungkin memutuskan untuk mengubah, misalnya, direktori data tempat data instans MySQL Anda berada. Setelah Anda menerapkan perubahan pada file konfigurasi Anda dan memulai ulang instans MySQL Anda, AppArmor akan menolak tindakan ini. Misalnya,

$ 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=1002

Bersama dengan kesalahan yang saya alami sebelumnya, sekarang ditambahkan bahwa saya baru saja memutuskan untuk menggunakan direktori /mysql-data tetapi itu ditolak.

Untuk menerapkan perubahan, lakukan hal berikut. Edit file /etc/apparmor.d/usr.sbin.mysqld. Anda mungkin menemukan baris berikut:

# 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

Halaman manual menjelaskan tanda tersebut secara lebih rinci.

Sekarang, saya telah mengubahnya menjadi berikut:

# Allow data dir access

  /mysql-data/ r,

  /mysql-data/** rwk,

Lalu saya reload profiles sebagai berikut:

$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqld

Mulai ulang server MySQL:

$ systemctl restart mysql.service

Bagaimana jika saya menyetel mysqld ke mode keluhan?

Seperti yang disebutkan sebelumnya, status mode keluhan akan tetap menerapkan aturan penolakan eksplisit apa pun di profil. Meskipun ini berfungsi misalnya:

$ aa-complain /usr/sbin/mysqld

Menyetel /usr/sbin/mysqld ke mode keluhan.

Lalu,

$ 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.

Setelah Anda me-restart MySQL, itu akan berjalan dan akan menampilkan file-file log seperti:

/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: 0

Dalam hal ini, menggunakan menegakkan dan memuat ulang profil Anda akan menjadi pendekatan yang efisien dan mudah untuk mengelola profil MySQL Anda dengan AppArmor.