Bug 588563 - SELinux is preventing /usr/bin/python "sys_tty_config" access.
Summary: SELinux is preventing /usr/bin/python "sys_tty_config" access.
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 12
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
: 588981 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-03 23:13 UTC by Mark Harig
Modified: 2010-06-16 17:07 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.6.32-114.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-18 21:55:33 UTC
Type: ---

Attachments (Terms of Use)

Description Mark Harig 2010-05-03 23:13:54 UTC
1. Description of problem:

During boot-up, four identical SELinux messages are written to the system log:

setroubleshoot: SELinux is preventing /usr/bin/python "sys_tty_config" access . For complete SELinux messages. run sealert -l c141dd46-907e-493b-bab6-7003769aaa59

2. Version-Release number of selected component (if applicable):

$ rpm -q selinux-policy selinux-policy-targeted python denyhosts


3. How reproducible:

This occurs during boot-up.  I have rebooted three times, and each time the four messages are generated.

I have also attempted to restart the 'denyhosts' service using the Fedora system-config-services applet (menu: System -> Administration -> Services).
This resulted in the 'system-config-services' process consuming 99 to 100% of the CPU cycles and never returning to user command.

4. Steps to Reproduce:

These 'setroubleshoot' messages were not being generated during boot up until I upgraded 'selinux-policy' and 'selinux-policy-targeted' to the package versions that were made available today (version 3.6.32-110 upgraded to

5. Additional info:

Here is an edited copy of the detailed setroubleshooter message:


SELinux is preventing /usr/bin/python "sys_tty_config" access .

Detailed Description:

[denyhosts.py has a permissive type (denyhosts_t). This access was not denied.]

SELinux denied access requested by denyhosts.py. It is not expected that this
access is required by denyhosts.py and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug

Additional Information:

Source Context                system_u:system_r:denyhosts_t:s0
Target Context                system_u:system_r:denyhosts_t:s0
Target Objects                None [ capability ]
Source                        denyhosts.py
Source Path                   /usr/bin/python
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           python-2.6.2-4.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-113.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain
                              #1 SMP Mon Apr 5 19:59:38 UTC 2010 x86_64 x86_64
Alert Count                   12
First Seen                    Mon 03 May 2010 05:47:56 PM EDT
Last Seen                     Mon 03 May 2010 06:40:23 PM EDT
Local ID                      c141dd46-907e-493b-bab6-7003769aaa59
Line Numbers                  

Raw Audit Messages            

node=localhost.localdomain type=AVC msg=audit(1272926423.474:10829): avc:  denied  { sys_tty_config } for  pid=1384 comm="denyhosts.py" capability=26  scontext=system_u:system_r:denyhosts_t:s0 tcontext=system_u:system_r:denyhosts_t:s0 tclass=capability

node=localhost.localdomain type=SYSCALL msg=audit(1272926423.474:10829): arch=c000003e syscall=16 success=yes exit=0 a0=2 a1=5401 a2=7fffd1a66340 a3=0 items=0 ppid=1383 pid=1384 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="denyhosts.py" exe="/usr/bin/python" subj=system_u:system_r:denyhosts_t:s0 key=(null)

Comment 1 Daniel Walsh 2010-05-04 17:25:16 UTC
I would expect this has more to do with the latest version of denyhosts.py

Seems strange that the python script would be touching the tty, but I guess we can add it.

Comment 2 Mark Harig 2010-05-04 17:49:28 UTC
(In reply to comment #1)
> I would expect this has more to do with the latest version of denyhosts.py

For what it's worth, denyhosts.py was not triggering this SELinux alert until yesterday when 'selinux-policy' was upgraded from 3.6.32-110 to 3.6.32-113.

> Seems strange that the python script would be touching the tty, but I guess we
> can add it.    

Perhaps the 'denyhosts' maintainers can comment?

Also, this report is similar to Bug #573180.

Comment 3 Miroslav Grepl 2010-05-05 09:13:10 UTC
*** Bug 588981 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Grepl 2010-05-05 11:07:46 UTC
Fixed in selinux-policy-3.6.32-114.fc12

Comment 5 Fedora Update System 2010-05-05 15:37:15 UTC
selinux-policy-3.6.32-114.fc12 has been submitted as an update for Fedora 12.

Comment 6 Fedora Update System 2010-05-07 03:57:56 UTC
selinux-policy-3.6.32-114.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-114.fc12

Comment 7 Mark Harig 2010-05-07 05:04:31 UTC
I have not updated selinux-policy or selinux-policy-targeted.

$ rpm -q selinux-policy selinux-policy-targeted

Each day this week (May 3, 4, 5) when I started Fedora 12, the SELinux errors were generated during the boot process.  But today (May 6), there were no errors that were generated during the boot process.

Yesterday, I updated the packages 'ibus', 'ibus-libs', and 'ibus-gtk'.

$ rpm -q ibus-libs ibus-gtk ibus

Today was the first day since that update that I have restarted Fedora 12.

This is the only change that I have made between yesterday when the SELinux errors were generated and today when they were not.

Here is some recent update history from /var/log/yum.log:

Apr 30 00:14:49 Updated: ibus-libs-1.3.2-2.fc12.x86_64
Apr 30 00:15:30 Updated: ibus-1.3.2-2.fc12.x86_64
Apr 30 00:15:38 Updated: ibus-gtk-1.3.2-2.fc12.x86_64

May 03 15:57:46 Updated: selinux-policy-3.6.32-113.fc12.noarch
May 03 15:59:52 Updated: selinux-policy-targeted-3.6.32-113.fc12.noarch

May 04 23:10:19 Updated: ibus-libs-1.3.2-3.fc12.x86_64
May 04 23:11:40 Updated: ibus-1.3.2-3.fc12.x86_64
May 04 23:11:44 Updated: ibus-gtk-1.3.2-3.fc12.x86_64

May 05 23:07:23 Updated: ibus-libs-1.3.3-1.fc12.x86_64
May 05 23:07:26 Updated: ibus-gtk-1.3.3-1.fc12.x86_64
May 05 23:07:49 Updated: ibus-1.3.3-1.fc12.x86_64

I do not know what the relationship is between the 'ibus' packages, the 'denyhosts' package, and the SELinux errors.  But at this time, those errors are no longer being generated.  I have rebooted Fedora 12 several times and restarted the 'denyhosts' service several times without any SELinux errors.

Comment 8 Daniel Stripes 2010-05-10 19:15:05 UTC
I have been having the same experience as in paragraph 1 of the original report posted above, with the same package revision levels indicated in paragraph 2 of the original report.

As for paragraph 3 of the original report, I have encountered this when using system-config-services to start/stop/enable/disable/edit other services than denyhosts, off-and-on for some time and don't consider it part of this bug/issue.

Paragraphs 4 and 5 of the original report posted above also accurately represent my experience and results.

After reading Comment 7 above, I tried reinstalling (yum reinstall) the ibus-libs-, ibus-gtk-, and ibus-1.3.3-1.fc12.x86_64 packages and rebooting:  same error message occurred.

I then reinstalled denyhosts-2.6-19.fc12.noarch and rebooted:  same error message.

I then installed the update indicated in Comment 6 above and rebooted and, of course, the error did not occur.  So far, I have not encountered any difficulty or issue with the selinux-policy- and selinux-policy-targeted-3.6.32-114.fc12.noarch updates.

This is the case for two (2) Intel Core i7 systems running here.

Comment 9 Fedora Update System 2010-05-18 21:54:50 UTC
selinux-policy-3.6.32-114.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Walter Neumann 2010-06-14 14:59:16 UTC
Seeing denials with selinux-policy-3.6.32-116.fc12

SELinux is preventing /usr/bin/python "search" access on /root/.local

I'm not sure why Denyhosts would want that access. Anyway, here are more details

Source Context:  system_u:system_r:denyhosts_t:s0Target Context:  system_u:object_r:gconf_home_t:s0
Target Objects:  /root/.local [ dir ]
Source:  denyhosts.pySource Path:  /usr/bin/python
Port:  <Unknown>Host:  lcn.homedns.org
Source RPM Packages:  python-2.6.2-4.fc12
Policy RPM:  selinux-policy-3.6.32-116.fc12

Platform:  Linux lcn.homedns.org #1 SMP Fri Apr 30 19:46:25 UTC 2010 x86_64 x86_64

First Seen:  Sat 12 Jun 2010 10:13:47 AM EDT

Raw Audit Messages :node=lcn.homedns.org type=AVC msg=audit(1276352027.101:11): avc: denied { search } for pid=2140 comm="denyhosts.py" name=".local" dev=dm-0 ino=624129 scontext=system_u:system_r:denyhosts_t:s0 tcontext=system_u:object_r:gconf_home_t:s0 tclass=dir

Comment 11 Daniel Walsh 2010-06-14 23:06:53 UTC
Could you just remove the .local file from /root.

Did you start the denyhosts.py from the /root directory?

Comment 12 Walter Neumann 2010-06-15 02:03:26 UTC
Denyhosts is one of the services started by init on boot, so it is certainly started by root. I assume init thinks it is in /root but I don't know for sure.

I did remove .local from /root after getting the denial, but I thought I should report it anyway.  I have no idea when/how .local got there in the first place.

Comment 13 Daniel Walsh 2010-06-16 17:07:59 UTC
I think it might get created by the login process.  If this problem comes back, please reopen.

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