Hello!
I have posted information regarding the error message I'm seeing at Github.com in the Pyzor forum located here:
https://github.com/SpamExperts/pyzor/issues/41#issuecomment-135539930
Basically, I was looking at the output of "journalctl -f" on my Fedora 21 system while trying to fine tune SpamAssassin the other day and found the following:
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.
Running the sealert command referenced above yields the following:
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 <Unknown> 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
Here is some relevant system info with respect to the system in question:
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
One of the guys at Github who initially responded indicated that, "There's nothing in Pyzor that would try to access /usr/bin/rpm." Evidently SELinux is upset at something so I figured it would be a good idea to also post on this list to see if anyone here knows anything I can do to help identify what's happening.
Thanks!
Tom
On 08/31/2015 08:28 PM, Tom Rivers wrote:
Hello!
I have posted information regarding the error message I'm seeing at Github.com in the Pyzor forum located here:
https://github.com/SpamExperts/pyzor/issues/41#issuecomment-135539930
Basically, I was looking at the output of "journalctl -f" on my Fedora 21 system while trying to fine tune SpamAssassin the other day and found the following:
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.
Running the sealert command referenced above yields the following:
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 <Unknown> 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
Here is some relevant system info with respect to the system in question:
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
One of the guys at Github who initially responded indicated that, "There's nothing in Pyzor that would try to access /usr/bin/rpm." Evidently SELinux is upset at something so I figured it would be a good idea to also post on this list to see if anyone here knows anything I can do to help identify what's happening.
It will be a library call and it would require more debugging. Basically I would also try to run it in permissive mode
# semanage permissive -a spamc_t
to see if you can get more AVCs.
Thanks!
Tom
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 9/1/2015 01:35, Miroslav Grepl wrote:
It will be a library call and it would require more debugging. Basically I would also try to run it in permissive mode
# semanage permissive -a spamc_t
to see if you can get more AVCs.
Thanks for the reply. I did as you directed and got a new AVC in addition to the one I identified previously:
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 <Unknown> 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 will continue to monitor the logs to see if anything else occurs.
Tom
On 9/1/2015 09:07, Tom Rivers wrote:
I will continue to monitor the logs to see if anything else occurs.
After some additional debug work, I managed to determine that the source of the problem was the incorrect ownership of the file /var/lib/spamass-milter/.pyzor/servers. It was not owned by the user under which pyzor executes and once it was properly adjusted the error messages stopped.
The more interesting piece of this puzzle, however, is the way in which SELinux is supposedly involved. According to one of the people helping me on the pyzor end of this, it isn't pyzor that is trying to access /usr/bin/rpm: he says it's abrt that is truly to blame. Here is what he posted:
"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."
If that is the case, then my question is this: why is SELinux blaming pyzor for something abrt is doing?
Tom
Abort must have been executed under the pyzor context. All SELinux is reporting what the kernel sees.
On 09/02/2015 12:46 PM, Tom Rivers wrote:
On 9/1/2015 09:07, Tom Rivers wrote:
I will continue to monitor the logs to see if anything else occurs.
After some additional debug work, I managed to determine that the source of the problem was the incorrect ownership of the file /var/lib/spamass-milter/.pyzor/servers. It was not owned by the user under which pyzor executes and once it was properly adjusted the error messages stopped.
The more interesting piece of this puzzle, however, is the way in which SELinux is supposedly involved. According to one of the people helping me on the pyzor end of this, it isn't pyzor that is trying to access /usr/bin/rpm: he says it's abrt that is truly to blame. Here is what he posted:
"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."
If that is the case, then my question is this: why is SELinux blaming pyzor for something abrt is doing?
Tom
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 9/2/2015 17:10, Daniel J Walsh wrote:
Abort must have been executed under the pyzor context. All SELinux is reporting what the kernel sees.
For the record, I freely admit to not understanding the mechanism by which this happened, so if I am totally off base with what I'm about to suggest I apologize for my ignorance.
Isn't the fact a separate entity like abrt can make itself look like python was to blame for something it did a cause for some concern? Is it possible some malicious program could use this same masquerade process to assume the identity of some other process and do things SELinux wouldn't normally allow?
Tom
On 09/03/2015 12:17 PM, Tom Rivers wrote:
On 9/2/2015 17:10, Daniel J Walsh wrote:
Abort must have been executed under the pyzor context. All SELinux is reporting what the kernel sees.
For the record, I freely admit to not understanding the mechanism by which this happened, so if I am totally off base with what I'm about to suggest I apologize for my ignorance.
Isn't the fact a separate entity like abrt can make itself look like python was to blame for something it did a cause for some concern? Is it possible some malicious program could use this same masquerade process to assume the identity of some other process and do things SELinux wouldn't normally allow?
Tom
If you can somehow get a confined application to execute a program and SELinux allows the executing of that program in the current context, then it will get the same privileges.
So yes if you can convince a program to do this you are potentially in trouble, but less trouble with SELinux then without.
As far as Abrt is concerned, I think there is some kernel mechanism at work here where applications somehow exec this helper when they crash.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
"TR" == Tom Rivers tom@impact-crater.com writes:
TR> If that is the case, then my question is this: why is SELinux TR> blaming pyzor for something abrt is doing?
Because it all happens in the context of the script. abrt basically hooks into the backtrace generation logic and runs some extra code. This doesn't happen in a separate process. Anyway, see https://github.com/abrt/abrt/issues/1042
This isn't really an selinux problem in any case.
- J<
On 9/2/2015 17:25, Jason L Tibbitts III wrote
TR> If that is the case, then my question is this: why is SELinux TR> blaming pyzor for something abrt is doing?
Because it all happens in the context of the script. abrt basically hooks into the backtrace generation logic and runs some extra code. This doesn't happen in a separate process.
It's the whole "abrt basically hooks into the backtrace generation logic" thing that I find particularly interesting. Your explanation makes it sound as if a separate program is able to gain access to an existing process and hide its true identity. I must be misunderstanding the nuts and bolts of this because malware does the exact same thing.
It makes sense to me that if a running process invokes an external program then that request will be under the context of the running process because it is what is making the request. However, a program that has the ability to take on the guise of some other process and make a request under a context that is not its own means it can hide. I don't see how that is a good thing especially with respect to programs like SELinux who must be able to clearly identify who is doing what in order to perform its role effectively.
Tom
On 09/03/2015 12:29 PM, Tom Rivers wrote:
On 9/2/2015 17:25, Jason L Tibbitts III wrote
TR> If that is the case, then my question is this: why is SELinux TR> blaming pyzor for something abrt is doing?
Because it all happens in the context of the script. abrt basically hooks into the backtrace generation logic and runs some extra code. This doesn't happen in a separate process.
It's the whole "abrt basically hooks into the backtrace generation logic" thing that I find particularly interesting. Your explanation makes it sound as if a separate program is able to gain access to an existing process and hide its true identity. I must be misunderstanding the nuts and bolts of this because malware does the exact same thing.
It makes sense to me that if a running process invokes an external program then that request will be under the context of the running process because it is what is making the request. However, a program that has the ability to take on the guise of some other process and make a request under a context that is not its own means it can hide. I don't see how that is a good thing especially with respect to programs like SELinux who must be able to clearly identify who is doing what in order to perform its role effectively.
Tom
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
SELinux does will not prevent a process with the proper rights from taking over another policy. unconfined_t or kernel_t are both allowed to do pretty much anything they want from an SELinux point of view. A confined process would obviously be blocked from doing this.
On 09/07/2015 01:44 PM, Daniel J Walsh wrote:
On 09/03/2015 12:29 PM, Tom Rivers wrote:
On 9/2/2015 17:25, Jason L Tibbitts III wrote
TR> If that is the case, then my question is this: why is SELinux TR> blaming pyzor for something abrt is doing?
Because it all happens in the context of the script. abrt basically hooks into the backtrace generation logic and runs some extra code. This doesn't happen in a separate process.
It's the whole "abrt basically hooks into the backtrace generation logic" thing that I find particularly interesting. Your explanation makes it sound as if a separate program is able to gain access to an existing process and hide its true identity. I must be misunderstanding the nuts and bolts of this because malware does the exact same thing.
It makes sense to me that if a running process invokes an external program then that request will be under the context of the running process because it is what is making the request. However, a program that has the ability to take on the guise of some other process and make a request under a context that is not its own means it can hide. I don't see how that is a good thing especially with respect to programs like SELinux who must be able to clearly identify who is doing what in order to perform its role effectively.
Tom
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
SELinux does will not prevent a process with the proper rights from taking over another policy. unconfined_t or kernel_t are both allowed to do pretty much anything they want from an SELinux point of view. A confined process would obviously be blocked from doing this. -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I believe there fixes in the latest Fedoras (F23/Rawhide). I would open a new bug and discuss it also with ABRT folks.
Thank you.
selinux@lists.fedoraproject.org