Cách cấu hình AppArmor cho các hệ thống dựa trên MySQL (MySQL / MariaDB Replication + Galera)

Tuần trước, chúng ta đã thảo luận về cách định cấu hình AppArmor cho Bộ bản sao MongoDB, về cơ bản có các khái niệm tương tự áp dụng khi định cấu hình bộ này cho hệ thống dựa trên MySQL của bạn. Thật vậy, bảo mật là rất quan trọng vì bạn phải đảm bảo rằng dữ liệu của bạn được bảo vệ rất tốt và được đóng gói để chống lại việc thu thập dữ liệu không mong muốn thông tin từ miền doanh nghiệp của bạn.

Một chút lịch sử về AppArmor

AppArmor lần đầu tiên được sử dụng trong Immunix Linux 1998–2003. Vào thời điểm đó, AppArmor được gọi là SubDomain, một tham chiếu đến khả năng cấu hình bảo mật cho một chương trình cụ thể được phân đoạn thành các miền khác nhau, mà chương trình có thể chuyển đổi động giữa các miền. AppArmor lần đầu tiên được cung cấp trong SLES và openSUSE, và lần đầu tiên được kích hoạt theo mặc định trong SLES 10 và openSUSE 10.1.

Vào tháng 5 năm 2005, Novell mua lại Immunix và đổi tên thành SubDomain thành AppArmor, đồng thời bắt đầu làm sạch và viết lại mã để đưa vào nhân Linux. Từ năm 2005 đến tháng 9 năm 2007, AppArmor được Novell duy trì. Novell đã được SUSE tiếp quản, hiện là chủ sở hữu hợp pháp của tên AppArmor đã đăng ký nhãn hiệu.

AppArmor lần đầu tiên được chuyển / đóng gói thành công cho Ubuntu vào tháng 4 năm 2007. AppArmor trở thành gói mặc định bắt đầu từ Ubuntu 7.10 và là một phần của bản phát hành Ubuntu 8.04, chỉ bảo vệ CUPS theo mặc định. Kể từ Ubuntu 9.04, nhiều mục như MySQL đã được cài đặt cấu hình. Việc tăng cường ứng dụng AppArmor tiếp tục được cải thiện trong Ubuntu 9.10 khi nó cung cấp các cấu hình cho phiên khách, máy ảo libvirt, trình xem tài liệu Evince và một cấu hình Firefox tùy chọn.

Tại sao chúng ta cần AppArmor?

Trong blog trước của chúng tôi, chúng tôi đã đề cập một chút về việc sử dụng AppArmor là gì. Đây là hệ thống Kiểm soát Truy cập Bắt buộc (MAC), được triển khai dựa trên Mô-đun Bảo mật Linux (LSM). Nó được sử dụng và chủ yếu được kích hoạt theo mặc định trong các hệ thống như Ubuntu, Debian (kể từ Buster), SUSE và các bản phân phối khác. Nó có thể so sánh với RHEL / CentOS SELinux, yêu cầu tích hợp không gian người dùng tốt để hoạt động bình thường. SELinux gắn nhãn cho tất cả các tệp, quy trình và đối tượng và do đó rất linh hoạt. Tuy nhiên, việc cấu hình SELinux được coi là rất phức tạp và yêu cầu một hệ thống tệp được hỗ trợ. Mặt khác, AppArmor hoạt động bằng cách sử dụng đường dẫn tệp và cấu hình của nó có thể dễ dàng điều chỉnh.

AppArmor, giống như hầu hết các LSM khác, bổ sung thay vì thay thế Điều khiển truy cập tùy ý (DAC) mặc định. Do đó, không thể cấp cho quy trình nhiều đặc quyền hơn so với quy trình ban đầu.

AppArmor chủ động bảo vệ hệ điều hành và các ứng dụng khỏi các mối đe dọa bên ngoài hoặc bên trong và thậm chí cả các cuộc tấn công zero-day bằng cách thực thi một bộ quy tắc cụ thể trên cơ sở từng ứng dụng. Các chính sách bảo mật hoàn toàn xác định tài nguyên hệ thống mà các ứng dụng riêng lẻ có thể truy cập và với những đặc quyền nào. Quyền truy cập bị từ chối theo mặc định nếu không có hồ sơ nào nói khác. Một số chính sách mặc định được bao gồm trong AppArmor và sử dụng kết hợp phân tích tĩnh nâng cao và các công cụ dựa trên học tập, các chính sách của AppArmor cho ngay cả các ứng dụng rất phức tạp có thể được triển khai thành công trong vài giờ.

Mọi vi phạm chính sách đều kích hoạt thông báo trong nhật ký hệ thống và AppArmor có thể được định cấu hình để thông báo cho người dùng với các cảnh báo vi phạm trong thời gian thực.

AppArmor dành cho MySQL

Tôi đã thiết lập một cụm dựa trên sao chép MySQL bằng cách sử dụng ClusterControl cho các nút cơ sở dữ liệu mục tiêu của tôi đang chạy trong Ubuntu Bionic. Bạn có thể theo dõi thêm blog này về cách triển khai nó hoặc làm theo hướng dẫn bằng video này. Lưu ý rằng ClusterControl kiểm tra hoặc tắt AppArmor trong quá trình triển khai. Bạn có thể phải bỏ chọn tùy chọn này theo thiết lập của mình giống như bên dưới:

ClusterControl sẽ chỉ đưa ra cảnh báo rằng nó không chạm vào cấu hình AppArmor hiện tại của bạn . Xem bên dưới:

Quản lý hồ sơ AppArmor của bạn

Cài đặt tiêu chuẩn AppArmor của bạn trong Ubuntu sẽ không bao gồm các tiện ích giúp quản lý cấu hình hiệu quả. Vì vậy, hãy cài đặt các gói này như sau:

$ apt install apparmor-profiles apparmor-utils

Sau khi cài đặt, hãy kiểm tra trạng thái của AppArmor trong hệ thống bằng cách chạy lệnh aa-status. Trong nút tôi đang sử dụng, tôi có kết quả đầu ra sau đây mà không cài đặt 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.

Vì tôi đang sử dụng ClusterControl để triển khai cụm dựa trên nhân bản MySQL của mình với AppArmor (tức là ClusterControl sẽ không chạm vào cấu hình AppArmor hiện tại của tôi), việc triển khai sẽ có cấu hình MySQL tại chỗ và hiển thị trong danh sách đang chạy 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.

Cần lưu ý rằng cấu hình ở một trong các chế độ sau:

Thực thi - Cài đặt mặc định. Các ứng dụng không được thực hiện các hành động bị hạn chế bởi các quy tắc hồ sơ.
Khiếu nại - Các ứng dụng được phép thực hiện các hành động bị hạn chế và các hành động này được ghi lại.
Đã tắt - Các ứng dụng được phép thực hiện các hành động bị hạn chế và các hành động này không được ghi lại.

Bạn cũng có thể kết hợp các cấu hình thực thi và khiếu nại trong máy chủ của mình.

Dựa trên kết quả ở trên, hãy trình bày chi tiết hơn về hồ sơ khiếu nại. AppArmor sẽ cho phép nó thực hiện (gần như trạng thái chế độ khiếu nại sẽ vẫn thực thi mọi quy tắc từ chối rõ ràng trong hồ sơ) tất cả các tác vụ mà không bị hạn chế nhưng nó sẽ ghi chúng vào nhật ký kiểm tra dưới dạng các sự kiện. Điều này hữu ích khi bạn đang cố gắng tạo hồ sơ cho một ứng dụng nhưng không chắc chắn những thứ mà nó cần truy cập. Mặt khác, trạng thái không xác định sẽ cho phép chương trình thực hiện bất kỳ tác vụ nào và sẽ không ghi lại tác vụ đó. Điều này thường xảy ra nếu một cấu hình được tải sau khi một ứng dụng được khởi động, nghĩa là nó chạy mà không có hạn chế từ AppArmor. Cũng cần lưu ý rằng chỉ các quy trình có cấu hình mới được liệt kê dưới trạng thái chưa xác định này. Bất kỳ quy trình nào khác chạy trên hệ thống của bạn nhưng không có cấu hình được tạo cho chúng sẽ không được liệt kê dưới trạng thái aa.

Nếu bạn đã tắt AppArmor nhưng sau đó nhận ra rằng bạn muốn tăng cường bảo mật hoặc tuân thủ các quy định bảo mật, bạn có thể sử dụng cấu hình MySQL 8.0 này do chính MySQL cung cấp. Để áp dụng điều đó, chỉ cần chạy lệnh sau:

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

Cần lưu ý rằng cấu hình AppArmor được lưu trữ theo mặc định trong /etc/apparmor.d/. Bạn nên thêm hồ sơ của mình vào thư mục đó.

Chẩn đoán cấu hình AppArmor của bạn

Nhật ký AppArmor có thể được tìm thấy trong tạp chí systemd, trong / var / log / syslog và /var/log/kern.log (và /var/log/audit.log khi audd được cài đặt). Những gì bạn cần tìm là:

ĐƯỢC PHÉP (đăng nhập khi hồ sơ ở chế độ khiếu nại vi phạm chính sách)
BỊ TỪ CHỐI (được ghi khi một cấu hình ở chế độ thực thi thực sự chặn một thao tác)

Thông báo nhật ký đầy đủ sẽ cung cấp thêm thông tin về quyền truy cập chính xác nào đã bị từ chối. Bạn có thể sử dụng quyền này để chỉnh sửa hồ sơ trước khi bật chúng ở chế độ thực thi.

Ví dụ:

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

Tùy chỉnh hồ sơ AppArmor của bạn

Các cấu hình do Oracle MySQL chuẩn bị sẽ không phải là một mẫu có kích thước phù hợp với tất cả. Trong trường hợp đó, bạn có thể quyết định thay đổi, ví dụ:thư mục dữ liệu nơi chứa dữ liệu phiên bản MySQL của bạn. Sau khi bạn áp dụng các thay đổi cho tệp cấu hình của mình và khởi động lại các phiên bản MySQL, AppArmor sẽ từ chối hành động này. Ví dụ:

$ 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

Cùng với lỗi mà tôi gặp phải trước đó, bây giờ nó cho biết thêm rằng tôi vừa quyết định sử dụng thư mục / mysql-data nhưng điều đó đã bị từ chối.

Để áp dụng các thay đổi, hãy làm như sau. Chỉnh sửa tệp /etc/apparmor.d/usr.sbin.mysqld. Bạn có thể tìm thấy những dòng sau:

# 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

Trang người đàn ông giải thích các cờ đó chi tiết hơn.

Bây giờ, tôi đã thay đổi nó thành như sau:

# Allow data dir access

  /mysql-data/ r,

  /mysql-data/** rwk,

Sau đó, tôi tải lại các cấu hình như sau:

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

Khởi động lại máy chủ MySQL:

$ systemctl restart mysql.service

Điều gì sẽ xảy ra nếu tôi đặt mysqld của mình ở chế độ khiếu nại?

Như đã đề cập trước đó, trạng thái chế độ khiếu nại sẽ vẫn thực thi mọi quy tắc từ chối rõ ràng trong hồ sơ. Mặc dù điều này hoạt động, ví dụ:

$ aa-complain /usr/sbin/mysqld

Đặt / usr / sbin / mysqld thành chế độ khiếu nại.

Sau đó,

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

Sau khi bạn khởi động lại MySQL, nó sẽ chạy và sẽ hiển thị các tệp nhật ký như:

/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

Trong trường hợp đó, sử dụng thực thi và tải lại hồ sơ của bạn sẽ là một cách tiếp cận hiệu quả và dễ dàng để quản lý hồ sơ MySQL của bạn với AppArmor.