Bug 599126 - SELinux is preventing /usr/sbin/named "write" access on log.
SELinux is preventing /usr/sbin/named "write" access on log.
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: 599128 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2010-06-02 13:48 EDT by Chris Miller
Modified: 2010-07-29 12:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-29 12:57:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Miller 2010-06-02 13:48:17 EDT

SELinux is preventing /usr/sbin/named "write" access on log.

Detailed Description:

SELinux denied access requested by named. It is not expected that this access is
required by named 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                unconfined_u:system_r:named_t:s0
Target Context                unconfined_u:object_r:device_t:s0
Target Objects                log [ sock_file ]
Source                        named
Source Path                   /usr/sbin/named
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           bind-9.7.0-9.P1.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-21.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed) #1 SMP
                              Thu May 13 05:55:24 UTC 2010 i686 i686
Alert Count                   2
First Seen                    Tue 01 Jun 2010 01:35:30 PM PDT
Last Seen                     Tue 01 Jun 2010 01:39:25 PM PDT
Local ID                      021066c0-635a-4d5e-b7c8-2c7158e528f0
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1275424765.966:41941): avc:  denied  { write } for  pid=26062 comm="named" name="log" dev=devtmpfs ino=1534170 scontext=unconfined_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=sock_file

node=(removed) type=SYSCALL msg=audit(1275424765.966:41941): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfe9b4dc a2=c51ff4 a3=ffffffc8 items=0 ppid=26061 pid=26062 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="named" exe="/usr/sbin/named" subj=unconfined_u:system_r:named_t:s0 key=(null)

Hash String generated from  catchall,named,named_t,device_t,sock_file,write
audit2allow suggests:

#============= named_t ==============
allow named_t device_t:sock_file write;
Comment 1 Daniel Walsh 2010-06-02 14:06:58 EDT
There looks like something is wrong with the labeling on your machine?  Or were you doing something with mock?

/dev/log should not be labeled device_t
Comment 2 Daniel Walsh 2010-06-02 14:07:19 EDT
*** Bug 599128 has been marked as a duplicate of this bug. ***
Comment 3 Chris Miller 2010-06-03 10:43:04 EDT
Hi Daniel,

I'm not doing anything with mock -- at least I have no such knowledge; if something else on my machine is misbehaving, then I can't explain it.

This is a quite recent fresh installation, so there should be no labeling "mistakes'.  The only "re-labeling" I have done would involve rdnc.key and getting DNS and DHCP to share access to authentication and security keys.  This would be restricted to /etc/dhcp* /etc/named* and /var/named/...  And I haven't added or modified any of the default labeling policy.

So, as you can tell, I am playing in the near vicinity, but I don't think I have done anything with "log" and I'm not sure I understand what SELinux means by "log"...

Hang on...  I frequently read /var/log/messages with vim.  If I were to accidently write out /var/log/messages as root, would that change it's labeling such that the above error would happen?

Comment 4 Daniel Walsh 2010-06-03 17:28:18 EDT

If you ran syslogd by hand this could happen.

What does 

ls -lZ /dev/log


ls -lZ /dev/log
srw-rw-rw-. root root system_u:object_r:devlog_t:s0    /dev/log

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