Bug 702889 - SELinux is preventing /bin/systemctl from 'read' accesses on the directory system.
Summary: SELinux is preventing /bin/systemctl from 'read' accesses on the directory sy...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 15
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:25a9767473d...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-08 03:34 UTC by cyrushmh
Modified: 2011-09-02 23:20 UTC (History)
33 users (show)

Fixed In Version: selinux-policy-3.9.16-24.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-25 03:29:53 UTC


Attachments (Terms of Use)

Description cyrushmh 2011-05-08 03:34:02 UTC
SELinux is preventing /bin/systemctl from 'read' accesses on the directory system.

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

If you believe that systemctl should be allowed read access on the system 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 systemctl /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:gnomeclock_systemctl_t:s0-s0:c0.
                              c1023
Target Context                system_u:object_r:init_var_run_t:s0
Target Objects                system [ dir ]
Source                        systemctl
Source Path                   /bin/systemctl
Port                          <未知>
Host                          (removed)
Source RPM Packages           systemd-units-26-1.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-23.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.38.5-24.fc15.x86_64 #1 SMP Fri May 6 08:00:28
                              UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    2011年05月08日 星期日 05时28分09秒
Last Seen                     2011年05月08日 星期日 05时28分09秒
Local ID                      ef02d27b-c0bb-4761-a181-e5bbea328e07

Raw Audit Messages
type=AVC msg=audit(1304803689.358:222): avc:  denied  { read } for  pid=6473 comm="systemctl" name="system" dev=tmpfs ino=8612 scontext=system_u:system_r:gnomeclock_systemctl_t:s0-s0:c0.c1023 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir


type=SYSCALL msg=audit(1304803689.358:222): arch=x86_64 syscall=open success=yes exit=EINTR a0=168d690 a1=90800 a2=35b8599230 a3=0 items=0 ppid=6454 pid=6473 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=systemctl exe=/bin/systemctl subj=system_u:system_r:gnomeclock_systemctl_t:s0-s0:c0.c1023 key=(null)

Hash: systemctl,gnomeclock_systemctl_t,init_var_run_t,dir,read

audit2allow

#============= gnomeclock_systemctl_t ==============
allow gnomeclock_systemctl_t init_var_run_t:dir read;

audit2allow -R

#============= gnomeclock_systemctl_t ==============
allow gnomeclock_systemctl_t init_var_run_t:dir read;

Comment 1 Miroslav Vadkerti 2011-05-08 19:23:17 UTC
Same bug here. Exact repro steps:
System Settings -> Date and time -> Enable network time

Comment 2 jkittsmiller2 2011-05-08 20:04:12 UTC
During boot-up I have to hit any key continuasly for my system to boot, once the system is booted the screen will not blank on idle like it is suposed to and the clock will not keep time, shutdown and suspen also reqire hiting of keys on the keyboard to complete.. Kernel 2.6.38.5-24

Comment 3 Miroslav Grepl 2011-05-09 15:21:31 UTC
gnomeclock_systemctl_t domain is permissive domain which means it should work.

From the raw AVC msg

success=yes

Comment 4 Daniel Walsh 2011-05-09 15:31:34 UTC
These avcs are n ot being deinied since the gnomeclock_systemctl_t is a
permissive domain.

type=SYSCALL msg=audit(1304803689.358:222): arch=x86_64 syscall=open
success=yes exit=EINTR a0=168d690 a1=90800 a2=35b8599230 a3=0 items=0 ppid=6454
pid=6473 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=systemctl exe=/bin/systemctl
subj=system_u:system_r:gnomeclock_systemctl_t:s0-s0:c0.c1023 key=(null)

If you look at the AVC you will see success=yes  Which means the open syscall 
was successful even though the AVC was denied.  The machine not suspending is
probably not related to this AVC.

I added the policy to allow gnomeclock_sysctl to list /run directory.

It should be in the next policy release.

Comment 5 Miroslav Grepl 2011-05-09 17:11:57 UTC
Fixed in selinux-policy-3.9.16-24.fc15

Comment 6 jkittsmiller2 2011-05-09 22:31:54 UTC
It'll suspend I just have to hit a key (any key) 3 times to get it to..

Comment 7 jkittsmiller2 2011-05-10 12:05:37 UTC
Sorry for posting this here, but I just found this and a slew of other fixes in the change log for for the 2.6.38.6 kernel at kernel.org, maybe someone could forward this information to the fedora kernel maintainers..

commit 15f0758f185241ad9c358a5bf60ff0a21eccc218
Author: Boris Ostrovsky <ostr@amd64.org>
Date:   Fri Apr 29 17:47:43 2011 -0400

    x86, AMD: Fix APIC timer erratum 400 affecting K8 Rev.A-E processors
    
    commit e20a2d205c05cef6b5783df339a7d54adeb50962 upstream.
    
    Older AMD K8 processors (Revisions A-E) are affected by erratum
    400 (APIC timer interrupts don't occur in C states greater than
    C1). This, for example, means that X86_FEATURE_ARAT flag should
    not be set for these parts.
    
    This addresses regression introduced by commit
    b87cf80af3ba4b4c008b4face3c68d604e1715c6 ("x86, AMD: Set ARAT
    feature on AMD processors") where the system may become
    unresponsive until external interrupt (such as keyboard input)
    occurs. This results, for example, in time not being reported
    correctly, lack of progress on the system and other lockups.
    
    Reported-by: Joerg-Volker Peetz <jvpeetz@web.de>
    Tested-by: Joerg-Volker Peetz <jvpeetz@web.de>
    Acked-by: Borislav Petkov <borislav.petkov@amd.com>
    Signed-off-by: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
    Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.org
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It was a regression after all...

Comment 8 Fedora Update System 2011-05-17 16:12:00 UTC
selinux-policy-3.9.16-24.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-24.fc15

Comment 9 Fedora Update System 2011-05-18 18:40:43 UTC
Package selinux-policy-3.9.16-24.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-24.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-24.fc15
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2011-05-25 03:29:01 UTC
selinux-policy-3.9.16-24.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


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