MySQL-आधारित सिस्टम के लिए AppArmor को कैसे कॉन्फ़िगर करें (MySQL/MariaDB प्रतिकृति + Galera)

पिछले हफ्ते, हमने चर्चा की कि MongoDB प्रतिकृति सेट के लिए AppArmor को कैसे कॉन्फ़िगर किया जाए, जिसमें मूल रूप से आपके MySQL-आधारित सिस्टम के लिए इसे कॉन्फ़िगर करते समय समान अवधारणाएं लागू होती हैं। वास्तव में, सुरक्षा बहुत महत्वपूर्ण है क्योंकि आपको यह सुनिश्चित करना है कि आपका डेटा बहुत अच्छी तरह से सुरक्षित है और आपके व्यावसायिक डोमेन से अवांछित डेटा एकत्र करने से सुरक्षित है।

AppArmor के बारे में थोड़ा सा इतिहास

AppArmor का पहली बार Immunix Linux 1998-2003 में उपयोग किया गया था। उस समय, AppArmor को SubDomain के रूप में जाना जाता था, एक विशिष्ट प्रोग्राम के लिए सुरक्षा प्रोफ़ाइल की क्षमता को विभिन्न डोमेन में विभाजित करने की क्षमता का संदर्भ, जिसे प्रोग्राम गतिशील रूप से स्विच कर सकता है। AppArmor को पहले SLES और openSUSE में उपलब्ध कराया गया था, और पहले डिफ़ॉल्ट रूप से SLES 10 और openSUSE 10.1 में सक्षम किया गया था।

मई 2005 में नोवेल ने Immunix का अधिग्रहण किया और उपडोमेन को AppArmor के रूप में पुनः ब्रांडेड किया और Linux कर्नेल में शामिल करने के लिए कोड सफाई और पुनर्लेखन शुरू किया। 2005 से सितंबर 2007 तक, नोवेल द्वारा AppArmor का रखरखाव किया गया था। नोवेल को SUSE ने अपने कब्जे में ले लिया जो अब ट्रेडमार्क नाम AppArmor के कानूनी मालिक हैं।

AppArmor को पहली बार अप्रैल 2007 में Ubuntu के लिए सफलतापूर्वक पोर्ट/पैक किया गया था। AppArmor Ubuntu 7.10 में शुरू होने वाला एक डिफ़ॉल्ट पैकेज बन गया, और Ubuntu 8.04 के रिलीज के एक भाग के रूप में आया, डिफ़ॉल्ट रूप से केवल CUPS की सुरक्षा करता है। उबंटू के रूप में 9.04 और अधिक आइटम जैसे कि MySQL ने प्रोफाइल स्थापित किए हैं। Ubuntu 9.10 में AppArmor हार्डनिंग में सुधार जारी रहा क्योंकि यह अपने अतिथि सत्र के लिए प्रोफाइल, libvirt वर्चुअल मशीन, Evince दस्तावेज़ व्यूअर और एक वैकल्पिक Firefox प्रोफ़ाइल के साथ शिप करता है।

हमें AppArmor की आवश्यकता क्यों है?

अपने पिछले ब्लॉग में, हमने ऐपआर्मर के उपयोग के बारे में कुछ बताया है। यह एक अनिवार्य अभिगम नियंत्रण (मैक) प्रणाली है, जिसे लिनक्स सुरक्षा मॉड्यूल (एलएसएम) पर लागू किया गया है। यह उबंटू, डेबियन (बस्टर के बाद से), एसयूएसई, और अन्य वितरण जैसे सिस्टम में डिफ़ॉल्ट रूप से उपयोग किया जाता है और अधिकतर सक्षम होता है। यह RHEL/CentOS SELinux से तुलनीय है, जिसे ठीक से काम करने के लिए अच्छे यूजरस्पेस एकीकरण की आवश्यकता होती है। SELinux सभी फाइलों, प्रक्रियाओं और वस्तुओं के लिए लेबल संलग्न करता है और इसलिए यह बहुत लचीला है। हालाँकि, SELinux को कॉन्फ़िगर करना बहुत जटिल माना जाता है और इसके लिए एक समर्थित फाइल सिस्टम की आवश्यकता होती है। दूसरी ओर, AppArmor फ़ाइल पथों का उपयोग करके काम करता है और इसके कॉन्फ़िगरेशन को आसानी से अनुकूलित किया जा सकता है।

AppArmor, अधिकांश अन्य LSM की तरह, डिफ़ॉल्ट डिस्क्रीशनरी एक्सेस कंट्रोल (DAC) को बदलने के बजाय पूरक है। इस तरह किसी प्रक्रिया को पहले की तुलना में अधिक विशेषाधिकार देना असंभव है।

AppArmor ऑपरेटिंग सिस्टम और एप्लिकेशन को बाहरी या आंतरिक खतरों और यहां तक कि शून्य-दिन के हमलों से प्रति-एप्लिकेशन के आधार पर निर्धारित एक विशिष्ट नियम को लागू करके सक्रिय रूप से बचाता है। सुरक्षा नीतियां पूरी तरह से परिभाषित करती हैं कि कौन से सिस्टम संसाधन अलग-अलग एप्लिकेशन एक्सेस कर सकते हैं, और किन विशेषाधिकारों के साथ। यदि कोई प्रोफ़ाइल अन्यथा नहीं कहती है, तो डिफ़ॉल्ट रूप से प्रवेश निषेध है। कुछ डिफ़ॉल्ट नीतियों को AppArmor के साथ शामिल किया गया है और उन्नत स्थैतिक विश्लेषण और सीखने-आधारित टूल के संयोजन का उपयोग करके, बहुत जटिल अनुप्रयोगों के लिए AppArmor नीतियों को कुछ ही घंटों में सफलतापूर्वक लागू किया जा सकता है।

नीति का हर उल्लंघन सिस्टम लॉग में एक संदेश को ट्रिगर करता है, और AppArmor को वास्तविक समय उल्लंघन चेतावनियों के साथ उपयोगकर्ताओं को सूचित करने के लिए कॉन्फ़िगर किया जा सकता है।

MySQL के लिए AppArmor

मैंने उबंटू बायोनिक में चल रहे अपने लक्ष्य डेटाबेस नोड्स के लिए क्लस्टरकंट्रोल का उपयोग करके एक MySQL-प्रतिकृति-आधारित क्लस्टर सेटअप किया है। आप आगे इस ब्लॉग का अनुसरण कर सकते हैं कि इसे कैसे परिनियोजित करें या इस वीडियो ट्यूटोरियल का अनुसरण करें। ध्यान दें कि ClusterControl परिनियोजन के दौरान AppArmor की जाँच या अक्षम करता है। आपको अपने सेटअप के अनुसार इसे नीचे की तरह अनचेक करना पड़ सकता है:

ClusterControl केवल एक चेतावनी जारी करेगा कि यह आपके वर्तमान AppArmor कॉन्फ़िगरेशन को नहीं छू रहा है . नीचे देखें:

अपना AppArmor प्रोफाइल प्रबंधित करना

उबंटू में आपके AppArmor की मानक स्थापना में उपयोगिताओं को शामिल नहीं किया जाएगा जो प्रोफाइल को कुशलतापूर्वक प्रबंधित करने में मदद करेगी। तो चलिए इन पैकेजों को इस तरह स्थापित करते हैं:

$ apt install apparmor-profiles apparmor-utils

इंस्टॉल हो जाने के बाद, सिस्टम में अपने AppArmor की स्थिति की जांच आ-स्टेटस कमांड चलाकर करें। मैं जिस नोड का उपयोग कर रहा हूं, उसमें मेरे पास 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.

चूंकि मैं अपने MySQL-प्रतिकृति आधारित क्लस्टर को AppArmor के साथ परिनियोजित करने के लिए ClusterControl का उपयोग कर रहा हूं (अर्थात ClusterControl मेरे वर्तमान AppArmor कॉन्फिगरेशन को नहीं छूएगा), परिनियोजन में MySQL प्रोफ़ाइल होनी चाहिए और जो इसमें दिखाई देती है एए-स्टेटस चलाने वाली सूची।

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

यह ध्यान देने योग्य है कि प्रोफ़ाइल निम्न में से किसी एक मोड में है:

प्रवर्तित करें - डिफ़ॉल्ट सेटिंग। एप्लिकेशन को प्रोफ़ाइल नियमों द्वारा प्रतिबंधित कार्रवाई करने से रोका जाता है।
शिकायत - एप्लिकेशन को प्रतिबंधित कार्रवाई करने की अनुमति है, और कार्रवाइयां लॉग की गई हैं।
अक्षम - एप्लिकेशन को प्रतिबंधित कार्रवाइयां करने की अनुमति है, और कार्रवाइयां लॉग नहीं की गई हैं।

आप अपने सर्वर में एनफोर्स और शिकायत प्रोफाइल को भी मिला सकते हैं।

उपरोक्त आउटपुट के आधार पर, प्रोफ़ाइल शिकायत के बारे में विस्तार से बताते हैं। AppArmor इसे प्रदर्शन करने की अनुमति देगा (लगभग शिकायत मोड की स्थिति अभी भी एक प्रोफ़ाइल में किसी भी स्पष्ट इनकार नियमों को लागू करेगी) सभी कार्यों को प्रतिबंध के बिना लेकिन यह उन्हें ऑडिट लॉग में घटनाओं के रूप में लॉग करेगा। यह तब उपयोगी होता है जब आप किसी एप्लिकेशन के लिए एक प्रोफ़ाइल बनाने का प्रयास कर रहे होते हैं, लेकिन यह सुनिश्चित नहीं होता है कि उसे किन चीज़ों तक पहुँच की आवश्यकता है। जबकि दूसरी ओर, असंबद्ध स्थिति प्रोग्राम को किसी भी कार्य को करने की अनुमति देगी और इसे लॉग नहीं करेगी। यह आमतौर पर तब होता है जब किसी एप्लिकेशन के शुरू होने के बाद प्रोफ़ाइल लोड की गई थी, जिसका अर्थ है कि यह AppArmor से प्रतिबंध के बिना चलती है। यह भी ध्यान रखना महत्वपूर्ण है कि केवल वे प्रक्रियाएं जिनमें प्रोफाइल हैं, इस अपुष्ट स्थिति के तहत सूचीबद्ध हैं। कोई अन्य प्रक्रिया जो आपके सिस्टम पर चलती है लेकिन उसके लिए कोई प्रोफ़ाइल नहीं बनाई गई है, उसे आ-स्थिति के अंतर्गत सूचीबद्ध नहीं किया जाएगा।

यदि आपने AppArmor को अक्षम कर दिया है, लेकिन तब आपको पता चलता है कि आप अपनी सुरक्षा बढ़ाना चाहते हैं या सुरक्षा नियमों का पालन करना चाहते हैं, तो आप इस MySQL 8.0 प्रोफ़ाइल का उपयोग कर सकते हैं जो MySQL द्वारा ही प्रदान की गई है। इसे लागू करने के लिए, बस निम्न कमांड चलाएँ:

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

यह ध्यान देने योग्य है कि AppArmor प्रोफाइल डिफ़ॉल्ट रूप से /etc/apparmor.d/ में संग्रहीत हैं। उस निर्देशिका में अपनी प्रोफ़ाइल जोड़ना एक अच्छा अभ्यास है।

अपने AppArmor प्रोफाइल का निदान करना

AppArmor लॉग सिस्टमड जर्नल में /var/log/syslog और /var/log/kern.log (और /var/log/audit.log जब ऑडिट स्थापित किया जाता है) में पाया जा सकता है। आपको जो देखने की आवश्यकता है वह निम्नलिखित है:

अनुमति दी गई है (जब शिकायत मोड में कोई प्रोफ़ाइल नीति का उल्लंघन करती है तो लॉग किया जाता है)
अस्वीकार किया गया (जब कोई प्रोफ़ाइल एनफोर्स मोड में वास्तव में किसी ऑपरेशन को ब्लॉक करती है तो लॉग किया जाता है)

पूर्ण लॉग संदेश को इस बारे में अधिक जानकारी प्रदान करनी चाहिए कि किस सटीक पहुंच से इनकार किया गया है। आप इसे लागू मोड में चालू करने से पहले प्रोफाइल को संपादित करने के लिए इसका उपयोग कर सकते हैं।

उदाहरण के लिए,

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

अपना AppArmor प्रोफ़ाइल कस्टमाइज़ करना

Oracle MySQL द्वारा तैयार प्रोफाइल एक आकार-फिट-सभी पैटर्न नहीं होना चाहिए। उस स्थिति में, आप बदलने का निर्णय ले सकते हैं, उदाहरण के लिए, डेटा निर्देशिका जहां आपका MySQL इंस्टेंस डेटा स्थित है। अपनी कॉन्फ़िगरेशन फ़ाइल में परिवर्तन लागू करने और अपने MySQL इंस्टेंस को पुनरारंभ करने के बाद, AppArmor इस क्रिया को अस्वीकार कर देगा। उदाहरण के लिए,

$ 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

एक साथ पहले की त्रुटि के साथ, अब यह जोड़ता है कि मैंने अभी-अभी /mysql-data निर्देशिका का उपयोग करने का निर्णय लिया था, लेकिन इसे अस्वीकार कर दिया गया है।

परिवर्तनों को लागू करने के लिए, निम्न कार्य करें। फ़ाइल /etc/apparmor.d/usr.sbin.mysqld संपादित करें। आपको ये पंक्तियाँ मिल सकती हैं:

# 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

मैन पेज उन झंडों के बारे में अधिक विस्तार से बताता है।

अब, मैंने इसे निम्न में बदल दिया है:

# Allow data dir access

  /mysql-data/ r,

  /mysql-data/** rwk,

फिर मैं प्रोफाइल को इस प्रकार पुनः लोड करता हूं:

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

MySQL सर्वर को पुनरारंभ करें:

$ systemctl restart mysql.service

यदि मैं अपने mysqld को शिकायत मोड में सेट कर दूं तो क्या होगा?

जैसा कि पहले उल्लेख किया गया है, शिकायत मोड की स्थिति अभी भी एक प्रोफ़ाइल में किसी भी स्पष्ट इनकार नियमों को लागू करेगी। हालांकि यह उदाहरण के लिए काम करता है:

$ aa-complain /usr/sbin/mysqld

शिकायत मोड में /usr/sbin/mysqld सेट करना।

फिर,

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

आपके द्वारा MySQL को पुनरारंभ करने के बाद, यह चलेगा और लॉग फ़ाइलें दिखाएगा जैसे:

/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

उस स्थिति में, AppArmor के साथ अपने MySQL प्रोफाइल को प्रबंधित करने के लिए अपनी प्रोफ़ाइल को लागू करना और पुनः लोड करना एक कुशल और आसान तरीका होगा।