{"id":288,"date":"2020-11-19T22:34:04","date_gmt":"2020-11-19T14:34:04","guid":{"rendered":"https:\/\/www.stusc.cn\/?p=288"},"modified":"2020-11-19T22:34:04","modified_gmt":"2020-11-19T14:34:04","slug":"how-to-read-and-correct-selinux-denial-messages","status":"publish","type":"post","link":"https:\/\/www.stusc.com\/?p=288","title":{"rendered":"How to read and correct SELinux denial messages"},"content":{"rendered":"\n<p>A look at SELinux denial messages, where they&#8217;re logged, and how to parse them.<\/p>\n\n\n\n<p>Posted: November 16, 2020 | byTyler Carrigan (Red Hat)<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/www.redhat.com\/sysadmin\/sites\/default\/files\/styles\/full\/public\/2020-11\/SELinux_Denial.jpg?itok=wNkQxVwX\" alt=\"SELinux denial messages\" \/><figcaption>Image by&nbsp;<a href=\"https:\/\/pixabay.com\/users\/alexas_fotos-686414\/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=3407481\">Alexas_Fotos<\/a>&nbsp;from&nbsp;<a href=\"https:\/\/pixabay.com\/?utm_source=link-attribution&amp;utm_medium=referral&amp;utm_campaign=image&amp;utm_content=3407481\">Pixabay<\/a><\/figcaption><\/figure>\n\n\n\n<p>Security Enhanced Linux (SELinux)&nbsp;is a security framework that allows and denies access to applications, files, etc. within a Linux system. For a full SELinux overview, see&nbsp;<a href=\"https:\/\/www.redhat.com\/en\/topics\/linux\/what-is-selinux\" target=\"_blank\" rel=\"noreferrer noopener\">What is SELinux<\/a>.<\/p>\n\n\n\n<p>For this article, we will look at what happens when access to a desired file or application is denied. What messages will you see, where are these messages stored, and what does the information actually mean? What are some of the abnormal situations, caused by false positives and ghost denials, that you might find yourself in? We will explore all of that here.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What is a denial?<\/h2>\n\n\n\n<p>A&nbsp;<em>denial<\/em>&nbsp;is the event generated anytime that a service, application, file, etc. is denied access by the SELinux system. When this happens, the denial is cached in the Access Vector Cache (AVC). You will sometimes see a denial message referred to as an&nbsp;<em>AVC denial<\/em>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Where are denials logged?<\/h2>\n\n\n\n<p>Now, these AVC denials, much like everything else in Linux, are logged by the system. Where those messages are logged varies depending on which system daemons are running.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>auditd on &#8211; \/var\/log\/audit\/audit.log<\/li><li>auditd off; rsyslogd on &#8211; \/var\/log\/messages<\/li><li>setroubleshootd, rsyslogd, and auditd on &#8211; Both locations, though the messages in \/var\/log\/messages are easier to make sense of<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">What will a denial look like?<\/h2>\n\n\n\n<p>You will sometimes see a denial warning on your desktop. When you select&nbsp;<strong>show<\/strong>, this alert will give you details as to what went wrong and even sometimes a solution to solve the problem.<\/p>\n\n\n\n<p>Another thing you can do is run the following commands to pull out the denial messages:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#091;root@server ~]# grep \"SELinux is preventing\" \/var\/log\/messages<\/code><\/pre>\n\n\n\n<p>Here the output is in more approachable language, and if you read carefully, a solution is presented:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Sep 22 13:35:24 server setroubleshoot&#091;3999]: SELinux is preventing rhsmcertd-worke from read access on the file virt.module. For complete SELinux messages run: sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b\nSep 22 13:35:24 server platform-python&#091;3999]: SELinux is preventing rhsmcertd-worke from read access on the file virt.module.#012#012***** \u00a0Plugin catchall_boolean (89.3 confidence) suggests \u00a0 ******************#012#012If you want to allow daemons to dump core#012Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.#012#012Do#012setsebool -P daemons_dump_core 1#012#012***** \u00a0Plugin catchall (11.6 confidence) suggests \u00a0 **************************#012#012If you believe that rhsmcertd-worke should be allowed read access on the virt.module file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke#012# semodule -X 300 -i my-rhsmcertdworke.pp#012<\/code><\/pre>\n\n\n\n<p>This output is actually really helpful, as the first entry above gives us the following:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>For complete SELinux messages run: sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b<\/code><\/pre>\n\n\n\n<p>If you run the suggested command, you are given a very verbose yet straightforward summary of what happened and what you can do to remedy the issue. Seen below:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>\u00a0 \u00a0 &#091;root@server ~]# sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b\n\u00a0 \u00a0 SELinux is preventing rhsmcertd-worke from read access on the file virt.module.\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 ***** \u00a0Plugin catchall_boolean (89.3 confidence) suggests \u00a0 ******************\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 If you want to allow daemons to dump core\n\u00a0 \u00a0 Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 Do\n\u00a0 \u00a0 setsebool -P daemons_dump_core 1\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 ***** \u00a0Plugin catchall (11.6 confidence) suggests \u00a0 **************************\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 If you believe that rhsmcertd-worke should be allowed read access on the virt.module file by default.\n\u00a0 \u00a0 Then you should report this as a bug.\n\u00a0 \u00a0 You can generate a local policy module to allow this access.\n\u00a0 \u00a0 Do\n\u00a0 \u00a0 allow this access for now by executing:\n\u00a0 \u00a0 # ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke\n\u00a0 \u00a0 # semodule -X 300 -i my-rhsmcertdworke.pp\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 Additional Information:\n\u00a0 \u00a0 Source Context \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0system_u:system_r:rhsmcertd_t:s0\n\u00a0 \u00a0 Target Context \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0system_u:object_r:root_t:s0\n\u00a0 \u00a0 Target Objects \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0virt.module &#091; file ]\n\u00a0 \u00a0 Source \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0rhsmcertd-worke\n\u00a0 \u00a0 Source Path \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 rhsmcertd-worke\n\u00a0 \u00a0 Port \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0&lt;Unknown&gt;\n\u00a0 \u00a0 Host \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0server.example.com\n\u00a0 \u00a0 Source RPM Packages \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\u00a0\n\u00a0 \u00a0 Target RPM Packages \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\u00a0\n\u00a0 \u00a0 Policy RPM \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0selinux-policy-3.14.3-41.el8_2.5.noarch\n\u00a0 \u00a0 Selinux Enabled \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 True\n\u00a0 \u00a0 Policy Type \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 targeted\n\u00a0 \u00a0 Enforcing Mode \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0Enforcing\n\u00a0 \u00a0 Host Name \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 server.example.com\n\u00a0 \u00a0 Platform \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0Linux server.example.com\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 4.18.0-193.13.2.el8_2.x86_64 #1 SMP Mon Jul 13\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 23:17:28 UTC 2020 x86_64 x86_64\n\u00a0 \u00a0 Alert Count \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 265\n\u00a0 \u00a0 First Seen \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a02020-06-24 13:55:40 EDT\n\u00a0 \u00a0 Last Seen \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 2020-09-22 13:35:09 EDT\n\u00a0 \u00a0 Local ID \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a097a1c0df-81ed-4c08-ba27-41c5067b713b\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 Raw Audit Messages\n\u00a0 \u00a0 type=AVC msg=audit(1600796109.687:168): avc: \u00a0denied \u00a0{ read } for \u00a0pid=3912 comm=\"rhsmcertd-worke\" name=\"virt.module\" dev=\"dm-0\" ino=50331783 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0\u00a0\n\u00a0 \u00a0 Hash: rhsmcertd-worke,rhsmcertd_t,root_t,file,read<\/code><\/pre>\n\n\n\n<p><em><strong>[ Readers also enjoyed:&nbsp;<a href=\"https:\/\/www.redhat.com\/sysadmin\/accessing-selinux-policy-documentation\" target=\"_blank\" rel=\"noreferrer noopener\">Accessing SELinux policy documentation<\/a>&nbsp;]<\/strong><\/em><\/p>\n\n\n\n<p>You can also use the command below for the raw audit messages, although they are significantly less helpful (and they are included in the&nbsp;<code>sealert<\/code>&nbsp;output).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#091;root@server ~]# grep \"denied\"\/var\/log\/audit\/audit.log<\/code><\/pre>\n\n\n\n<p>Here the language is less user-friendly, and there are no suggested steps to take.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>type=AVC msg=audit(1600796109.687:168): avc: \u00a0denied \u00a0{ read } for \u00a0pid=3912 comm=\"rhsmcertd-worke\" name=\"virt.module\" dev=\"dm-0\" ino=50331783 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Ghost denials<\/h2>\n\n\n\n<p>On special occasions (<em>special<\/em>, as in their ability to generate frustration), the SELinux AVC can deny a service without alerting the user that the denial occurred. When this happens, a little forensic digging is needed. Recently, my colleague, and writer extraordinaire, Ken Hess, installed a document management system on a CentOS virtual machine. During this installation, the DMS failed to install with no explanation. After a long, frustrating troubleshooting process, Ken discovered that there were repeated denial messages in&nbsp;<code>\/var\/log\/audit\/audit.log<\/code>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>type=AVC msg=audit(1602171971.334:438): avc: denied { write } for pid=12398 comm=\"httpd\" name=\"31b32f0dfa1f50d778065b767582bb9b.js\" dev=\"dm-0\" ino=553885 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file permissive=0<\/code><\/pre>\n\n\n\n<p>Upon further inspection of&nbsp;<code>\/var\/log\/messages<\/code>, he found the following:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Oct 8 12:33:17 dms python: SELinux is preventing \/usr\/sbin\/httpd from name_connect access on the tcp_socket port 25.#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow httpd to can network connect#012Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean.#012#012Do#012setsebool -P httpd_can_network_connect 1#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow httpd to can sendmail#012Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean.#012#012Do#012setsebool -P httpd_can_sendmail 1#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow nis to enabled#012Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.#012#012Do#012setsebool -P nis_enabled 1#012#012***** Plugin catchall (4.5 confidence) suggests ***************************#012#012If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'httpd' --raw | audit2allow -M my-httpd#012# semodule -i my-httpd.pp#012 Oct 8 12:33:20 dms setroubleshoot: SELinux is preventing \/usr\/sbin\/httpd from name_connect access on the tcp_socket port 25. For complete SELinux messages run: sealert -l ce75fc38-5696-4b21-b099-7780db5960f3<\/code><\/pre>\n\n\n\n<p>Finally, something useful. He then ran the this command:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># sealert -l ce75fc38-5696-4b21-b099-7780db5960f3<\/code><\/pre>\n\n\n\n<p>Which provided this information:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>&#091;user@host ~] # SELinux is preventing \/usr\/sbin\/httpd from name_connect access on the tcp_socket port 25. ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can network connect Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean. Do setsebool -P httpd_can_network_connect 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can sendmail Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean. Do setsebool -P httpd_can_sendmail 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (4.5 confidence) suggests *************************** If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'httpd' --raw | audit2allow -M my-httpd # semodule -i my-httpd.pp Additional Information:\n\u00a0 \u00a0\u00a0\nAdditional Information: &#091;root@dms dms]# more sealert.txt SELinux is preventing \/usr\/sbin\/httpd from name_connect access on the tcp_socket port 25. ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can network connect Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean. Do setsebool -P httpd_can_network_connect 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can sendmail Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean. Do setsebool -P httpd_can_sendmail 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (4.5 confidence) suggests *************************** If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'httpd' --raw | audit2allow -M my-httpd # semodule -i my-httpd.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:smtp_port_t:s0 Target Objects port 25 &#091; tcp_socket ] Source httpd Source Path \/usr\/sbin\/httpd Port 25 Host dms Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-252.el7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name dms Platform Linux dms 3.10.0-1062.el7.x86_64 #1 SMP Wed Aug 7 18:08:02 UTC 2019 x86_64 x86_64 Alert Count 2 First Seen 2020-10-08 12:33:15 CDT Last Seen 2020-10-08 12:33:15 CDT Local ID ce75fc38-5696-4b21-b099-7780db5960f3 Raw Audit Messages type=AVC msg=audit(1602178395.253:461): avc: denied { name_connect } for pid=12565 comm=\"httpd\" dest=25 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:smtp_port_t :s0 tclass=tcp_socket permissive=1 Hash: httpd,httpd_t,smtp_port_t,tcp_socket,name_connect<\/code><\/pre>\n\n\n\n<p>When I asked Ken to weigh in on his experience, he had the following to say:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\"><p>It&#8217;s hard to know when an error, or lack of an error, is caused by SELinux. When you&#8217;ve checked firewall exceptions, filesystem permissions, and application prerequisites, your next step is to check SELinux context issues. The most common remedy is to disable SELinux by placing it into Permissive mode, which isn&#8217;t a good idea because doing so leaves your system vulnerable. The better method is to check the \/var\/log\/messages and the \/var\/log\/audit\/audit.log files for SELinux denials and work from there to individually remedy the denials until your application works. SELinux needs to remain in Enforcing mode to do this.<\/p><p>The troubleshooting list looks like the following when setting up a new application:<\/p><p>1. Check firewall exceptions for your application&#8217;s ports.<\/p><p>2. Check filesystem permissions to ensure that your service account has the correct permissions to read, write, and execute where necessary.<\/p><p>3. Check your application&#8217;s prerequisites and dependencies.<\/p><p>4. Check the \/var\/log\/messages and \/var\/log\/audit\/audit.log files for SELinux denials.<\/p><p>SELinux Permissive mode can be used briefly to check if SELinux is the culprit in preventing your application from working. Once you&#8217;ve determined it to be the problem, return it to Enforcing mode and begin changing relevant contexts.&nbsp;<a href=\"https:\/\/access.redhat.com\/documentation\/en-us\/red_hat_enterprise_linux\/6\/html\/security-enhanced_linux\/chap-security-enhanced_linux-selinux_contexts\" target=\"_blank\" rel=\"noreferrer noopener\">See this information for SELinux contexts<\/a>.<\/p><\/blockquote>\n\n\n\n<p><em><strong>[ Improve your skills managing and using SELinux with this&nbsp;<a href=\"https:\/\/opensource.com\/downloads\/cheat-sheet-selinux?intcmp=701f20000012ngPAAQ\" target=\"_blank\" rel=\"noreferrer noopener\">helpful guide<\/a>. ]&nbsp;<\/strong><\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wrap up<\/h2>\n\n\n\n<p>SELinux is an effective security framework that can be incredibly useful when correctly implemented. As with any good security system, you will have denials over time. Knowing what to do with the information at your disposal is paramount to solving any issues that may be present or for allowing legitimate processes through the system. Now you know where the logs are kept and how to best interpret them. In the future, you&#8217;ll be able to respond to any SELinux alerts that flag on your system.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Check out these related articles on Enable Sysadmin<\/h3>\n","protected":false},"excerpt":{"rendered":"<p>A look at SELinux denial messages, where they&#8217;re logged, and how to parse them.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[72],"class_list":{"0":"post-288","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"hentry","6":"category-tech","7":"tag-selinux","8":"h-entry","10":"h-as-article"},"_links":{"self":[{"href":"https:\/\/www.stusc.com\/index.php?rest_route=\/wp\/v2\/posts\/288","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.stusc.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.stusc.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.stusc.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.stusc.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=288"}],"version-history":[{"count":1,"href":"https:\/\/www.stusc.com\/index.php?rest_route=\/wp\/v2\/posts\/288\/revisions"}],"predecessor-version":[{"id":289,"href":"https:\/\/www.stusc.com\/index.php?rest_route=\/wp\/v2\/posts\/288\/revisions\/289"}],"wp:attachment":[{"href":"https:\/\/www.stusc.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=288"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.stusc.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=288"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.stusc.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=288"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}