1:28 p.m.
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(a)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
12:35 a.m.
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
8:07 a.m.
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
11:46 a.m.
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
4:10 p.m.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
11:17 a.m.
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
6:42 a.m.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
4:25 p.m.
>>>> "TR" == Tom Rivers
<tom(a)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<
11:29 a.m.
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
6:44 a.m.
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(a)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.
3 a.m.
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(a)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(a)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.
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
3152
days inactive
3161
days old
selinux@lists.fedoraproject.org
10 comments
4 participants
participants (4)
-
Daniel J Walsh -
Jason L Tibbitts III -
Miroslav Grepl -
Tom Rivers