Today, I decided to have a quick revision on SELinux as it’s been a long while that I worked on any projects that required my attention to fiddling with SELinux. While I was looking for an sealert in /var/log/messages on my Fedora based desktop, I found a real issue that I need to fix. Like most of my blog posts, I’d like to start writing the post while I was about to solve the issue. ...
Today, I want to run the httpd server on a custom port, 8002 on a CentOS 7 server. Of course, all my system has SELinux in enforcing mode. In order for the httpd to bind on port 8002, we need to add this port to the httpd_port_t port type list. First let’s confirm that port 8002 is not yet in the http_port_t list: [root@servera ~]# semanage port -l | grep ^http http_cache_port_t tcp 8080, 8118, 8123, 10001-10010 http_cache_port_t udp 3130 http_port_t tcp 80, 81, 443, 488, 8008, 8009, 8443, 9000 We know from the manual semanage-port(8), to add a port to an SELinux port type list, we run the following command: ...
On most my systems I created a user called devops with its home directory created at /srv/devops. And on Fedora or CentOS systems, those home directories have their SELinux context set correctly when created. Recently, I found out that on all 3 machines so far, the SELinux context has been reverted. ~# ls -lZ /srv total 0 drwx------. 5 devops devops system_u:object_r:var_t:s0 127 Oct 30 2019 devops It should have had the same context as the normal user kenno in /home directory: ...
What? Why does mpd want to access /root/.config? What’s MPD? It’s a daemon for playing music. It runs as a service, which I connect to with either ncmp or ncmpcpp. Here’s the full SETroubleshoot detail: SELinux is preventing mpd from getattr access on the directory /root/.config. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that mpd should be allowed getattr access on the .config directory 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 'mpd' --raw | audit2allow -M my-mpd # semodule -X 300 -i my-mpd.pp Additional Information: Source Context system_u:system_r:mpd_t:s0 Target Context unconfined_u:object_r:config_home_t:s0 Target Objects /root/.config [ dir ] Source mpd Source Path mpd Port Host watamem.local Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-283.26.fc27.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name watamem.local Platform Linux watamem.local 4.15.4-300.fc27.x86_64 #1 SMP Mon Feb 19 23:31:15 UTC 2018 x86_64 x86_64 Alert Count 2 First Seen 2018-03-01 19:37:10 AEDT Last Seen 2018-03-01 19:40:15 AEDT Local ID 95638a12-2d84-4060-9339-8f05c61c619e Raw Audit Messages type=AVC msg=audit(1519893615.831:1060): avc: denied { getattr } for pid=23997 comm="mpd" path="/root/.config" dev="dm-0" ino=1703951 scontext=system_u:system_r:mpd_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=dir permissive=0 Hash: mpd,mpd_t,config_home_t,dir,getattr The version of MPD that causes this issue is: 0.20.10 on Fedora 27. I’m pretty sure it was working last week and I didn’t have to do anything. So what’s changed? Well, it seems like this could be a very old problem as reported int bug 1325502. Basically, when mpd is started, it tries to read the MPD configuration file (mpd.conf). According to the man page for mpd.conf, the configuration file should be read in the following order: ...