Bug 156457 - Chroot-ed named access denied to write/remove/rename log files
Chroot-ed named access denied to write/remove/rename log files
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-30 12:43 EDT by Robert Nichols
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 14:12:19 EDT
Type: ---
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 Robert Nichols 2005-04-30 12:43:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3

Description of problem:
When named (bind) is started in its chroot jail, multiple "avc: denied" messages
are generated.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.17.30-2.96

How reproducible:
Always

Steps to Reproduce:
1. With SELinux in "permissive" mode, start the "named" service.


Actual Results:  Messages like the following are logged for files in /var/named/chroot/var/log/:

audit(1114877586.037:0): avc:  denied  { write } for  pid=17867 exe=/usr/sbin/named name=log dev=hda6 ino=201387 scontext=user_u:system_r:named_t tcontext=root:object_r:named_conf_t tclass=dir

audit(1114877586.037:0): avc:  denied  { remove_name } for  pid=17867 exe=/usr/sbin/named name=named-info.log.1 dev=hda6 ino=201386 scontext=user_u:system_r:named_t tcontext=root:object_r:named_conf_t tclass=dir
audit(1114877586.038:0): avc:  denied  { rename } for  pid=17867 exe=/usr/sbin/named name=named-info.log.1 dev=hda6 ino=201386 scontext=user_u:system_r:named_t tcontext=user_u:object_r:named_conf_t tclass=file

audit(1114877586.038:0): avc:  denied  { add_name } for  pid=17867 exe=/usr/sbin/named name=named-info.log.2 dev=hda6 ino=201388 scontext=user_u:system_r:named_t tcontext=root:object_r:named_conf_t tclass=dir

audit(1114877586.038:0): avc:  denied  { unlink } for  pid=17867 exe=/usr/sbin/named name=named-info.log.2 dev=hda6 ino=201388 scontext=user_u:system_r:named_t tcontext=user_u:object_r:named_conf_t tclass=file

audit(1114877586.039:0): avc:  denied  { create } for  pid=17867 exe=/usr/sbin/named name=named-info.log scontext=user_u:system_r:named_t tcontext=user_u:object_r:named_conf_t tclass=file


Expected Results:  No complaints.

Additional info:

bind-9.2.5-1, bind-chroot-9.2.5-1

No changes from running "restorecon -Rv /var/named".
Comment 1 Colin Walters 2005-05-03 15:32:30 EDT
Do you have any specific reason to run named in a chroot?  The SELinux policy
alone should provide stronger security.
Comment 2 Robert Nichols 2005-05-04 11:10:29 EDT
The bind-chroot package gets installed by default when you select the "DNS
Nameserver" group at install time.  No, I don't have a specific need to run
named in a chroot jail.  For that matter I do not have any specific reason to
run SELinux and have no plans to use "enforcing" mode.  I'm just reporting a
conflict between selinux-policy-targeted and the default installation of the
DNS nameserver.
Comment 3 Daniel Walsh 2005-05-12 15:41:40 EDT
What is /var/named/chroot/var/log/?

This is not part of a standard install.

Dan
Comment 4 Jason Vas Dias 2005-05-12 16:53:09 EDT
Yes, you should be installing the bind-chroot package to run named in a 
chroot environment.
Modern BIND named calls openlog() BEFORE doing the chroot, and thus does not
require /dev/log in the chroot.
It does, however, require the proc filesystem to be mounted under the chroot's
/proc for various sysctl and networking calls to work correctly, which you'd
get if you have bind-chroot and bind-9.3.1-+ / bind-9.2.5-+ installed.


Comment 5 Robert Nichols 2005-05-12 18:33:37 EDT
Here's what happened.  I have a logging statement requesting logging to a file
/var/log/named-info.log and not by using the syslog facility.  BIND is creating
that file, and rotating existing versions of that file, in the chrooted
environment.  Here's named.conf logging statement that causes the problem:

logging {
    channel info_log {
        file "/var/log/named-info.log" versions 3;
        severity info;
    };
    category default {
        info_log;
    };
};

As I originally noted, I do have bind-9.2.5-1 and bind-chroot-9.2.5-1
installed.  There is no /proc filesystem in the chrooted environment,
nor is there a /dev/log there.

This is looking like multiple bugs in the BIND packages, rather than a
problem in SELinux.
Comment 6 Jason Vas Dias 2005-05-13 11:45:36 EDT
There is BIND SELinux policy only for the files and directories installed as
part of the BIND package.
If you want named to create new files in directories not shipped as part of
the BIND package, then you need to create SELinux policy for them - for your
/var/log directory, you'd need to do:
  # touch /var/named/var/log/named-info.log
  # chown -R named:named /var/named/var/log 
  # chcon -R system_u:object_r:named_cache_t /var/named/var/log
We can't provide SELinux policy for every new file and directory that 
named may be configured to touch.
We do provide policy for named to create files in the $ROOTDIR/var/named/data
and $ROOTDIR/var/named/slaves directory, but it is up to users to configure
named to place new files there.
For the next version of BIND, I'll be updating the named man-page with more 
documentation about the SELinux policy issues.
And for the next bind-9.2.5 release for FC-3, the /proc filesystem will be
mounted under the chroot.

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