Bug 832582 - When running a sealert -l <sealert number> results in WARNING: Policy will be downgraded.... then WARNING Trying to register gtype
When running a sealert -l <sealert number> results in WARNING: Policy will be...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pygtk2 (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-15 16:23 EDT by Neil Squires
Modified: 2013-08-01 09:07 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 09:07:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil Squires 2012-06-15 16:23:16 EDT
Description of problem:
The logcheck program is running and generating an email with the following 
System Events
=-=-=-=-=-=-=
Jun 16 01:02:01 grandma setroubleshoot: SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.3vFhyg. For complete SELinux messages. run sealert -l 60671784-6eed-422d-bcca-82579fbbc373

When you run sealert you get the following errors before the main body:

[root@grandma ~]# sealert -l 60671784-6eed-422d-bcca-82579fbbc373
WARNING: Policy would be downgraded from version 27 to 26.

** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.aGtOH9.



Version-Release number of selected component (if applicable): setroubleshoot.x86_64 3.1.11-1.fc17


How reproducible: everytime I run an sealert message


Steps to Reproduce:
1.enter any sealert message 
2.
3.
  
Actual results:
WARNING: Policy would be downgraded from version 27 to 26.

** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (setroubleshoot:29220): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.aGtOH9.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that mktemp should be allowed create access on the logcheck.aGtOH9 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:
# grep mktemp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


WARNING: Policy would be downgraded from version 27 to 26.
WARNING: Policy would be downgraded from version 27 to 26.
Additional Information:
Source Context                system_u:system_r:logwatch_t:s0-s0:c0.c1023
Target Context                system_u:object_r:user_tmp_t:s0
Target Objects                logcheck.aGtOH9 [ dir ]
Source                        mktemp
Source Path                   /usr/bin/mktemp
Port                          <Unknown>
Host                          grandma.dbay.squires.id.au
Source RPM Packages           coreutils-8.15-6.fc17.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.10.0-128.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     grandma.dbay.squires.id.au
Platform                      Linux grandma.dbay.squires.id.au
                              3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC
                              2012 x86_64 x86_64
Alert Count                   7
First Seen                    Fri 15 Jun 2012 11:02:01 PM EST
Last Seen                     Sat 16 Jun 2012 05:02:02 AM EST
Local ID                      60671784-6eed-422d-bcca-82579fbbc373

Raw Audit Messages
type=AVC msg=audit(1339786922.292:983): avc:  denied  { create } for  pid=28114 comm="mktemp" name="logcheck.aGtOH9" scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir


type=SYSCALL msg=audit(1339786922.292:983): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=da40b0 a1=1c0 a2=0 a3=d49bdb6fb677b899 items=0 ppid=28106 pid=28114 auid=992 uid=992 gid=989 euid=992 suid=992 fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=94 comm=mktemp exe=/usr/bin/mktemp subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)

Hash: mktemp,logwatch_t,user_tmp_t,dir,create

audit2allow

#============= logwatch_t ==============
allow logwatch_t user_tmp_t:dir create;

audit2allow -R

#============= logwatch_t ==============
allow logwatch_t user_tmp_t:dir create;


Expected results:

SELinux is preventing /usr/bin/mktemp from create access on the directory logcheck.aGtOH9.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that mktemp should be allowed create access on the logcheck.aGtOH9 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:
# grep mktemp /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


WARNING: Policy would be downgraded from version 27 to 26.
WARNING: Policy would be downgraded from version 27 to 26.
Additional Information:
Source Context                system_u:system_r:logwatch_t:s0-s0:c0.c1023
Target Context                system_u:object_r:user_tmp_t:s0
Target Objects                logcheck.aGtOH9 [ dir ]
Source                        mktemp
Source Path                   /usr/bin/mktemp
Port                          <Unknown>
Host                          grandma.dbay.squires.id.au
Source RPM Packages           coreutils-8.15-6.fc17.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.10.0-128.fc17.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     grandma.dbay.squires.id.au
Platform                      Linux grandma.dbay.squires.id.au
                              3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC
                              2012 x86_64 x86_64
Alert Count                   7
First Seen                    Fri 15 Jun 2012 11:02:01 PM EST
Last Seen                     Sat 16 Jun 2012 05:02:02 AM EST
Local ID                      60671784-6eed-422d-bcca-82579fbbc373

Raw Audit Messages
type=AVC msg=audit(1339786922.292:983): avc:  denied  { create } for  pid=28114 comm="mktemp" name="logcheck.aGtOH9" scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=dir


type=SYSCALL msg=audit(1339786922.292:983): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=da40b0 a1=1c0 a2=0 a3=d49bdb6fb677b899 items=0 ppid=28106 pid=28114 auid=992 uid=992 gid=989 euid=992 suid=992 fsuid=992 egid=989 sgid=989 fsgid=989 tty=(none) ses=94 comm=mktemp exe=/usr/bin/mktemp subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)

Hash: mktemp,logwatch_t,user_tmp_t,dir,create

audit2allow

#============= logwatch_t ==============
allow logwatch_t user_tmp_t:dir create;

audit2allow -R

#============= logwatch_t ==============
allow logwatch_t user_tmp_t:dir create;


Additional info: There is also a bug in the logcheck rpm. When I installed it, the selinux policy prevents usr/bin/mktemp from creating directories in /tmp

After running the multipule alert messages I have generated the following policy

module logcheck 1.0;

require {
        type user_tmp_t;
        type logwatch_t;
        class dir { write create add_name };
}

#============= logwatch_t ==============
allow logwatch_t user_tmp_t:dir create;
#!!!! This avc is allowed in the current policy

allow logwatch_t user_tmp_t:dir { write add_name };
Comment 1 Daniel Walsh 2012-06-15 16:38:04 EDT
Policy will be downgraded will be fixed when the 3.5 kernel arrives.  This is telling you that you have a newer tool chain then the kernel supports.

The other warnings come from 

import gtk
Comment 2 Fedora End Of Life 2013-07-04 00:17:55 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 3 Fedora End Of Life 2013-08-01 09:07:48 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.