Bug 964587 - SELinux is preventing ntpdate from 'read, write' accesses on the chr_file /dev/mapper/control.
Summary: SELinux is preventing ntpdate from 'read, write' accesses on the chr_file /de...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-19 03:43 UTC by Mukundan Ragavan
Modified: 2013-05-29 21:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-29 21:53:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mukundan Ragavan 2013-05-19 03:43:40 UTC
The following SEalert appears at every login.

Description of problem:

SELinux is preventing ntpdate from 'read, write' accesses on the chr_file /dev/mapper/control.

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

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

Additional Information:
Source Context                system_u:system_r:ntpd_t:s0
Target Context                system_u:object_r:lvm_control_t:s0
Target Objects                /dev/mapper/control [ chr_file ]
Source                        ntpdate
Source Path                   ntpdate
Port                          <Unknown>
Host                          hydrogen
Source RPM Packages           ntpdate-4.2.6p5-11.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-44.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     hydrogen
Platform                      Linux hydrogen 3.9.2-301.fc19.x86_64 #1 SMP Mon
                              May 13 12:36:24 UTC 2013 x86_64 x86_64
Alert Count                   4
First Seen                    2013-05-18 16:11:08 CDT
Last Seen                     2013-05-18 16:11:08 CDT
Local ID                      4b846941-3def-4f24-9f59-35d2d11f23d5

Raw Audit Messages
type=AVC msg=audit(1368911468.989:401): avc:  denied  { read write } for  pid=1180 comm="ntpdate" path="/dev/mapper/control" dev="devtmpfs" ino=6899 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:object_r:lvm_control_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1368911468.989:401): arch=x86_64 syscall=execve success=yes exit=0 a0=1e87e90 a1=1e88490 a2=1e86f60 a3=7fff164a2bf0 items=0 ppid=1178 pid=1180 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=ntpdate exe=/usr/sbin/ntpdate subj=system_u:system_r:ntpd_t:s0 key=(null)

Hash: ntpdate,ntpd_t,lvm_control_t,chr_file,read,write

audit2allow

#============= ntpd_t ==============
allow ntpd_t lvm_control_t:chr_file { read write };

audit2allow -RYou must regenerate interface info by running /usr/bin/sepolgen-ifgen


Version-Release number of selected component (if applicable):
Fedora 19, beta RC2

selinux-policy-3.12.1-44.fc19.noarch

ntpdate-4.2.6p5-11.fc19.x86_64

Additional info:
Honestly, I do not know if this is a bug!

Comment 1 Miroslav Grepl 2013-05-20 11:13:41 UTC
Do you know what you were doing when this happened?

Comment 2 Mukundan Ragavan 2013-05-20 13:30:48 UTC
I had just logged in. Nothing else. 

I have XFCE desktop set to remember sessions and so thunderbird was also starting.

Comment 3 Daniel Walsh 2013-05-21 15:58:13 UTC
I am not sure the login has anything to do with this.  setroubleshoot is going to show you alerts that happened while you were not logged in, so sealert showing you the alert when you logged in.  The alert could have happened earlier.

Comment 4 Mukundan Ragavan 2013-05-21 16:43:32 UTC
Sorry. What I meant was I did not have to do anything to get the sealert notification. I meant to say I logged in and immediately saw the notification. That's it!

Comment 5 Daniel Walsh 2013-05-23 13:57:57 UTC
That is what I figured. Does this continue to happen?  On Boot?

Comment 6 Mukundan Ragavan 2013-05-23 16:50:31 UTC
Yes. Every time. Reboot/{log out & log in} - does not matter. I get sealert about this.

Comment 7 Miroslav Grepl 2013-05-29 12:06:45 UTC
Could you try to delete the alert and see if you get it again. Thank you.

Comment 8 Mukundan Ragavan 2013-05-29 13:50:28 UTC
No. I am not getting the alert anymore. I was keeping track of the timestamps on the alerts and I did get new alerts before but not now.

I have updated a few times in the meanwhile but I do not know if the updates have anything to do with this though.

Comment 9 Daniel Walsh 2013-05-29 21:53:54 UTC
Well reopen if it happens again.


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