SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm
Closed this issue · 17 comments
I'm running a Fedora 21 system and have noticed that SELinux complains with this error message quite frequently. Sometimes it is preceded by the following error but not every time:
python[22066]: detected unhandled Python exception in '/usr/bin/pyzor'
Below are some more specifics regarding the system:
kernel-4.1.5-100.fc21.x86_64
pyzor-0.5.0-10.fc21.noarch
Python 2.7.8 (default, Apr 15 2015, 09:26:43)
[GCC 4.9.2 20150212 (Red Hat 4.9.2-6)] on linux2
If it should have access then I want to file a bug report with the SELinux folks but I figured it made sense to start here. Can someone tell me why pyzor is attempting to access this file?
Thanks!
There's nothing in Pyzor that would try to access /usr/bin/rpm. Where do you see reference to that (there's nothing in the error log you included that shows it)?
The "unhandled Python exception" issue means that Pyzor has crashed in some way. Do you know where the output ends up? (I don't know Fedora, sorry). It should have the details of what's going wrong.
It would be good to have the entire AVC message. What's in the subject is incomplete. Still, there's simply no reason it would need to call RPM but without complete information it's really tough to tell what's happening.
In addition, F21's pyzor is pretty old, sorry. I was unsure of whether it was safe to push the latest version out to everyone so I left it alone (and forgot to actually ask here about it). F23 has 1.0.0 and if I can push it to folks who have existing, running 0.5 installs without breaking them then I'll look into doing that.
Thanks for the replies, guys. I didn't want to bother posting a bunch of details unless it made sense for someone here to look into this. As requested, here is the entire SELinux message:
SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that pyzor should be allowed getattr access on the rpm file 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:
grep pyzor /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:spamc_t:s0
Target Context system_u:object_r:rpm_exec_t:s0
Target Objects /usr/bin/rpm [ file ]
Source pyzor
Source Path pyzor
Port
Host impact-crater.com
Source RPM Packages
Target RPM Packages rpm-4.12.0.1-7.fc21.x86_64
Policy RPM selinux-policy-3.13.1-105.20.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name impact-crater.com
Platform Linux impact-crater.com 4.1.5-100.fc21.x86_64 #1
SMP Tue Aug 11 00:24:23 UTC 2015 x86_64 x86_64
Alert Count 33
First Seen 2015-08-27 08:35:55 EDT
Last Seen 2015-08-27 09:36:08 EDT
Local ID 09532028-c2c0-472e-b39f-c52ef00c5dc6
Raw Audit Messages
type=AVC msg=audit(1440682568.916:5869): avc: denied { getattr } for pid=22308 comm="pyzor" path="/usr/bin/rpm" dev="dm-1" ino=1977835 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file permissive=0
Hash: pyzor,spamc_t,rpm_exec_t,file,getattr
With respect to finding where additional information ends up from the "unhandled Python exception", I'm getting this from systemd by running "journalctl -f". It isn't any more verbose that what I have posted previously, so I suspect that I will need to do something else to capture additional debug information. I'm willing to make whatever adjustments are required to deliver whatever information you need.
What's odd is that you know it isn't trying to access /usr/bin/rpm but SELinux sure thinks it is.
I snagged the related lines in the system log outputted by journalctl if this helps at all:
Aug 27 09:33:16 impact-crater.com spamd[20895]: spamd: processing message 20150827133258.6E19C61B70D1@bastion01.phx2.fedoraproject.org for sa-milt:986
Aug 27 09:33:17 impact-crater.com python[22066]: detected unhandled Python exception in '/usr/bin/pyzor'
Aug 27 09:33:17 impact-crater.com setroubleshoot[7528]: SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm. For complete SELinux messages. run sealert -l 09532028-c2c0-472e-b39f-c52ef00c5dc6
Aug 27 09:33:17 impact-crater.com python[7528]: SELinux is preventing pyzor from getattr access on the file /usr/bin/rpm.
I raised this same issue on the Fedora SELinux list which you can find here: https://lists.fedoraproject.org/pipermail/selinux/2015-September/016830.html
Basically he suggested I run the following command to allow Pyzor to do what it needs to do in order to dig a little deeper into what's happening:
semanage permissive -a spamc_t
Once I did that, I get the same AVC I posted previously plus the following:
SELinux is preventing pyzor from open access on the file /var/lib/rpm/Packages.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that pyzor should be allowed open access on the Packages file 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:
grep pyzor /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:spamc_t:s0
Target Context system_u:object_r:rpm_var_lib_t:s0
Target Objects /var/lib/rpm/Packages [ file ]
Source pyzor
Source Path pyzor
Port
Host impact-crater.com
Source RPM Packages
Target RPM Packages rpm-4.12.0.1-7.fc21.x86_64
Policy RPM selinux-policy-3.13.1-105.20.fc21.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name impact-crater.com
Platform Linux impact-crater.com 4.1.5-100.fc21.x86_64 #1
SMP Tue Aug 11 00:24:23 UTC 2015 x86_64 x86_64
Alert Count 1
First Seen 2015-09-01 09:01:22 EDT
Last Seen 2015-09-01 09:01:22 EDT
Local ID cd8cd6d0-38a1-40df-b4ea-34ab2020625a
Raw Audit Messages
type=AVC msg=audit(1441112482.875:16788): avc: denied { open } for pid=22386 comm="pyzor" path="/var/lib/rpm/Packages" dev="dm-1" ino=2103007 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file permissive=1
Hash: pyzor,spamc_t,rpm_var_lib_t,file,open
I'm continuing to monitor the issue and will report anything new that occurs. Does this latest AVC help at all?
Thanks!
Oops - pushed the wrong button! Sorry, I'm still getting used to this interface and didn't mean to close the issue.
On 8/27/2015 16:10, Tony Meyer wrote:
There's nothing in Pyzor that would try to access /usr/bin/rpm. Where
do you see reference to that (there's nothing in the error log you
included that shows it)?
I put some more information in the forum that might help.
The "unhandled Python exception" issue means that Pyzor has crashed in
some way. Do you know where the output ends up? (I don't know Fedora,
sorry). It should have the details of what's going wrong.
I managed to find a problem directory created by abrt that I believe
contains pertinent information. I've attached a tar/gzipped archive to
this email message that contains the directory's contents. It appears
to be a permission issue. Here's the backtrace:
client.py:1031:download:IOError: [Errno 13] Permission denied:
'/var/lib/spamass-milter/.pyzor/servers'
Traceback (most recent call last):
File "/usr/bin/pyzor", line 8, in
pyzor.client.run()
File "/usr/lib/python2.7/site-packages/pyzor/client.py", line 1022,
in run
ExecCall().run()
File "/usr/lib/python2.7/site-packages/pyzor/client.py", line 186, in run
download(config.get('client', 'DiscoverServersURL'), servers_fn)
File "/usr/lib/python2.7/site-packages/pyzor/client.py", line 1031,
in download
open(outfile, "wb").write(urllib2.urlopen(url).read())
IOError: [Errno 13] Permission denied:
'/var/lib/spamass-milter/.pyzor/servers'
Local variables in innermost frame:
url: 'http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x'
outfile: '/var/lib/spamass-milter/.pyzor/servers'
urllib2: <module 'urllib2' from '/usr/lib64/python2.7/urllib2.pyc'>
Tom
OK, so a .TGZ attachment isn't supported. If you need the rest of the data, just let me know and I can either post the contents here or make the archive available another way. It contains the following files:
-rw-r----- root/abrt 5 2015-09-01 09:01 ./abrt_version
-rw-r----- root/abrt 6 2015-09-01 09:01 ./analyzer
-rw-r----- root/abrt 6 2015-09-01 09:01 ./architecture
-rw-r----- root/abrt 892 2015-09-01 09:01 ./backtrace
-rw-r----- root/abrt 65 2015-09-01 09:01 ./cmdline
-rw-r----- root/abrt 5 2015-09-01 09:01 ./component
-rw-r----- root/abrt 2 2015-09-01 09:25 ./count
-rw-r----- root/abrt 40 2015-09-01 09:01 ./duphash
-rw-r----- root/abrt 172 2015-09-01 09:01 ./environ
-rw-r----- root/abrt 14 2015-09-01 09:01 ./executable
-rw-r----- root/abrt 17 2015-09-01 09:01 ./hostname
-rw-r----- root/abrt 21 2015-09-01 09:01 ./kernel
-rw-r----- root/abrt 10 2015-09-01 09:25 ./last_occurrence
-rw-r----- root/abrt 377 2015-09-01 09:01 ./os_info
-rw-r----- root/abrt 30 2015-09-01 09:01 ./os_release
-rw-r----- root/abrt 19 2015-09-01 09:01 ./package
-rw-r----- root/abrt 5 2015-09-01 09:01 ./pid
-rw-r----- root/abrt 6 2015-09-01 09:01 ./pkg_arch
-rw-r----- root/abrt 1 2015-09-01 09:01 ./pkg_epoch
-rw-r----- root/abrt 5 2015-09-01 09:01 ./pkg_name
-rw-r----- root/abrt 7 2015-09-01 09:01 ./pkg_release
-rw-r----- root/abrt 5 2015-09-01 09:01 ./pkg_version
-rw-r----- root/abrt 103 2015-09-01 09:01 ./reason
-rw-r----- root/abrt 4 2015-09-01 09:01 ./runlevel
-rw-r----- root/abrt 10 2015-09-01 09:01 ./time
-rw-r----- root/abrt 6 2015-09-01 09:01 ./type
-rw-r----- root/abrt 3 2015-09-01 09:01 ./uid
-rw-r----- root/abrt 8 2015-09-01 09:01 ./username
-rw-r----- root/abrt 40 2015-09-01 09:01 ./uuid
Tom
We're way beyond my knowledge of SELinux / Fedora, unfortunately.
Pyzor is a pretty simple Python application. The client doesn't have any dependencies other than Python itself, and it doesn't execute any other process. It will try and load a configuration file from $HOME/.pyzor or /etc/pyzor. It may write to the temporary folder to handle some types of input. It won't (in recent versions, at least) write anywhere else.
This is extra complicated since you're using such an old version, and it's a distro package rather than the regular one, and from the look of things also installed as part of SpamAssassin.
I'm afraid I won't really be much more help here (and I'm guessing that the other Pyzor developers won't be either). Hopefully someone else can figure this out (e.g. @jasontibbitts from above).
I think I may have found the source of the problem. The directory on my system for Pyzor is:
/var/lib/spamass-milter/.pyzor
The "servers" file resides there and it was not owned by the user under which pyzor executes. Once I changed the ownership of the "servers" file to the proper user, the errors went away. Just to be sure that was what fixed the problem, I went back and made root the owner and the problems resurfaced.
Not having looked at the source code for Pyzor, my guess is that perhaps it is trying to use the RPM database to reset ownership settings for the files in the package. The following code would do just that:
/bin/rpm --setugids pyzor-0.5.0-10.fc21.noarch
That would explain the call to "rpm" if, in fact, the program is trying to correct the issue itself. Since it is unusual for a program like Pyzor to request access to /bin/rpm, SELinux steps in and shuts it down.
Does this sound plausible?
There's no writing to the servers file any more (that whole system was simplified long ago - it's a bit of a miracle that the http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x URL even still works).
Even 0.5 definitely did not ever execute rpm directly. It could be that the distro package you have has some patch that does that - do you have some place where I could download it to look? Maybe @jasontibbitts knows the answer to this?
I really appreciate all the help! Here is a mirror that has the package I'm using:
If there's anything else I can do to help just let me know.
TL;DR: The selinux failure accessing rpm is a complete red herring and has nothing to do with pyzor at all. Tom should just have reported this in bugzilla and not bothered the devs; I would have reassigned it to abrt (eventually). If I've missed a filed ticket, though, I apologize.
Lots of typing:
I'm not sure what the devs would do with an rpm. If they want to look at the actual package source, it's at http://pkgs.fedoraproject.org/cgit/pyzor.git/tree/ There's not much to it; Fedora applies no patches and it's pretty much the simplest package you can get.
How, I did some digging and have an explanation for the selinux/rpm thing. The issue is that pyzor is backtracing and Tom has abrt installed and running. abrt logs and optionally auto-files bugs whenever (among other things) a distro-installed python application backtraces. It calls rpm to see which to which package the backtracing script belongs in order to classify it properly. This kind of doesn't work well for confined applications, but that's definitely not pyzor's bug. I don't know if this has been fixed since.
abrt info, for anyone interested, is at https://github.com/abrt/abrt/wiki/ABRT-Project
The stuff that abrt reports is at https://retrace.fedoraproject.org and everything it's collected for pyzor is at https://retrace.fedoraproject.org/faf/problems/?component_names=pyzor
However, I doubt that's particularly useful to the devs as there are no reports involving 1.0.0.
Tom is of course welcome to just build and install the current package on F21. Tom, if you don't know how to do that, let me know and I'll give you a package. Or you could just try installing the current F23 package. I think it should install just fine. My guess is that you'll have to redo any configuration you had but feel free to let me know about your experience.
Also, note https://bugzilla.redhat.com/show_bug.cgi?id=1199339, though that was fixed a while ago. The current package makes sure that the configuration stuff goes into /etc/pyzor and that selinux is OK with that. There may still be selinux issues, though, and if seen should simply be filed at bugzilla.redhat.com.
Thanks for the reply, Jason. In my own defense, I posted something here because I was looking for precisely the answer you just gave me: it belongs in bugzilla. I'm a software developer myself and I wanted to be sure I didn't just blindly cause a stir and raise a red flag with people who shouldn't be involved and have much bigger fish to fry. My bad. Sorry for the noise.
Thanks for the information regarding why SELinux is involved in this issue - great catch! I'll be sure to pass this along to the folks at the Fedora SELinux list.
Rather than mix and match a Fedora23 Pyzor package with a Fedora21 system, I'm just going to bite the bullet, back everything up, and upgrade to the latest release.
Thanks to everyone for all the excellent help!
I can always forward a ticket upstream if necessary; that's my job as a package maintainer.
That sounds good to me. When you do, could you post a link to it here? I would love to learn more about the process and reviewing what you are going to file seems like a good place to start. I've done plenty of coding and debugging of my own code and also with code I work with at my job, but have never really become formally involved in public bug reporting. I think it's about time I do.
Thanks again for all your help!