The problem
I am trying to set up SMART monitoring for my disks on my Fedora Server 36 installation. I have installed smartmontools and have the following configuration in /etc/smartmontools/smartd.conf
:
DEFAULT -a -m <nomailer> -M exec /usr/local/bin/smartd_alert.py -M test
/dev/nvme0
/dev/disk/by-partlabel/data1
/dev/disk/by-partlabel/data2
/dev/disk/by-partlabel/parity1
I am using the -m exec
directive to run an alert script instead of using the mailer functionality. The Python script sends the notification to me via a 3rd party service (Pushbullet).
This has worked for me on previous Fedora releases. However, with Fedora 36, the Python script is failing with name resolution after starting the smartd service:
socket.gaierror: [Errno -3] Temporary failure in name resolution
This does not happen if I run the script as-is from the shell, only if it is run via the smartd service.
Investigation
I googled for a bit and found out about a SELinux troubleshooting tool, so I installed it and ran it:
sudo dnf install setroubleshoot-server
sudo sealert -a /var/log/audit/audit.log
This prints the following output:
100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing python from name_connect access on the tcp_socket port 443.
***** Plugin catchall_boolean (89.3 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 (11.6 confidence) suggests **************************
If you believe that python should be allowed name_connect access on the port 443 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 'python' --raw | audit2allow -M my-python
# semodule -X 300 -i my-python.pp
Additional Information:
Source Context system_u:system_r:fsdaemon_t:s0
Target Context system_u:object_r:http_port_t:s0
Target Objects port 443 [ tcp_socket ]
Source python
Source Path python
Port 443
Host <Unknown>
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-36.10-1.fc36.noarch
Local Policy RPM smartmontools-selinux-7.3-2.fc36.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name lunatea
Platform Linux lunatea 5.18.5-200.fc36.x86_64 #1 SMP
PREEMPT_DYNAMIC Thu Jun 16 14:51:11 UTC 2022
x86_64 x86_64
Alert Count 56
First Seen 2022-07-29 21:06:22 EEST
Last Seen 2022-07-29 22:01:34 EEST
Local ID 0addaf3a-f2b0-4f33-bf01-cf954ba10495
Raw Audit Messages
type=AVC msg=audit(1659121294.93:468): avc: denied { name_connect } for pid=1770 comm="python" dest=443 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
Hash: python,fsdaemon_t,http_port_t,tcp_socket,name_connect
So the root of the issue seems to be SELinux limiting Pythonâs networking capabilities, for whatever reason.
The questions
I have very little knowledge of SELinux, so I am in need of guidance here.
First, the sealert tool seems to suggest that I should enable the nis_enabled
boolean. I have no idea what the security implications of this are, so I am not comfortable running that command blindly. I do not want any unintended side effects. All I know is that I absolutely expect a Python script to be able to make network requests regardless of whether I run it via the shell or a systemd service. I do not necessarily want to make changes to any other default security rules set in Fedora by default.
Secondly, the tool also suggests â with less confidence â that this may actually be a bug. I donât think I have enough knowledge to conclude whether this is intended behaviour or not. But it does seem weird to me that I cannot make network requests in my Python programs. The tool also offers a method to generate a local policy to allow the access. I do not know if this is a better/safer method than the nis_enabled
thing.
So the questions are:
- Am I doing something wrong here?
- Should I report this as a bug on BugZilla?
- Can the
nis_enabled
boolean be safely enabled to allow Python scripts to make network requests, but without negatively affecting the security of the system? - Instead of the
nis_enabled
method, would it be better to generate a local policy specifically to enable Python network access (and nothing else)?