Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1511269 - Startup failures due to AVCs
Summary: Startup failures due to AVCs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 03:05 UTC by Ed Marshall
Modified: 2020-02-12 10:02 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.13.1-283.16.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-20 16:57:01 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Ed Marshall 2017-11-09 03:05:27 UTC 
After upgrading from Fedora 26 to Fedora 27, nsd (nsd-4.1.16-3.fc27.x86_64) no longer starts, with the following logged in the journal:

Nov 09 02:54:35 host.domain.com systemd[1]: Started NSD DNS Server.
Nov 09 02:54:35 host.domain.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 09 02:54:35 host.domain.com nsd[1223]: nsd starting (NSD 4.1.16)
Nov 09 02:54:35 host.domain.com nsd[1223]: [2017-11-09 02:54:35.792] nsd[1223]: notice: nsd starting (NSD 4.1.16)
Nov 09 02:54:35 host.domain.com audit[1223]: AVC avc:  denied  { map } for  pid=1223 comm="nsd" path="/tmp/nsd-xfr-1223/nsd.1223.task.0" dev="vda1" ino=5459 scontext=system_u:system_r:nsd_t:s0 tcontext=system_u:object_r:nsd_tmp_t:s0 tclass=file permissive=0
Nov 09 02:54:35 host.domain.com nsd[1223]: mmap(size 288) error: Permission denied
Nov 09 02:54:35 host.domain.com nsd[1223]: [2017-11-09 02:54:35.800] nsd[1223]: error: mmap(size 288) error: Permission denied
Nov 09 02:54:35 host.domain.com nsd[1223]: rmdir /tmp/nsd-xfr-1223 failed: Directory not empty
Nov 09 02:54:35 host.domain.com nsd[1223]: [2017-11-09 02:54:35.801] nsd[1223]: warning: rmdir /tmp/nsd-xfr-1223 failed: Directory not empty
Nov 09 02:54:35 host.domain.com systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Nov 09 02:54:35 host.domain.com audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nsd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Nov 09 02:54:35 host.domain.com systemd[1]: nsd.service: Unit entered failed state.
Nov 09 02:54:35 host.domain.com audit[1]: AVC avc:  denied  { read } for  pid=1 comm="systemd" name="nsd-xfr-1223" dev="vda1" ino=4046 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:nsd_tmp_t:s0 tclass=dir permissive=0
Nov 09 02:54:35 host.domain.com systemd[1]: nsd.service: Failed with result 'exit-code'.

It looks like NSD is trying to mmap files in /tmp (for xfr), which I don't think is new behavior. audit2allow -e suggests:

#============= init_t ==============
# 
#  scontext="system_u:system_r:init_t:s0" tcontext="system_u:object_r:nsd_tmp_t:s0"
#  class="dir" perms="read"
#  comm="systemd" exe="" path=""
#  message="Nov 09 02:54:35 host.domain.com audit[1]: AVC avc:  denied  { read }
#   for  pid=1 comm="systemd" name="nsd-xfr-1223" dev="vda1" ino=4046
#   scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:nsd_tmp_t:s0
#   tclass=dir permissive=0 "
allow init_t nsd_tmp_t:dir read;

#============= nsd_t ==============
# 
#  scontext="system_u:system_r:nsd_t:s0" tcontext="system_u:object_r:nsd_tmp_t:s0"
#  class="file" perms="map"
#  comm="nsd" exe="" path=""
#  message="Nov 09 02:54:35 host.domain.com audit[1223]: AVC avc:  denied  { map
#   } for  pid=1223 comm="nsd" path="/tmp/nsd-xfr-1223/nsd.1223.task.0"
#   dev="vda1" ino=5459 scontext=system_u:system_r:nsd_t:s0
#   tcontext=system_u:object_r:nsd_tmp_t:s0 tclass=file permissive=0 "
allow nsd_t nsd_tmp_t:file map;
Comment 1 Stefan Paletta 2017-11-14 17:50:06 UTC 
I can confirm this problem. Here is a policy file to work around the new nsd behavior not covered by the current policy:

module nsd_tmp_fixup 1.0;

require {
        type nsd_t;
        type nsd_tmp_t;
        type nsd_zone_t;
        class file { map };
}

#============= nsd_t ==============
allow nsd_t nsd_tmp_t:file map;
allow nsd_t nsd_zone_t:file map;
Comment 2 Fedora Update System 2017-11-16 15:12:59 UTC 
selinux-policy-3.13.1-283.16.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5178e6a393
Comment 3 Fedora Update System 2017-11-17 18:56:42 UTC 
selinux-policy-3.13.1-283.16.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5178e6a393
Comment 4 Fedora Update System 2017-11-20 16:57:01 UTC 
selinux-policy-3.13.1-283.16.fc27 has been pushed to the Fedora 27 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.