Bug 566287 - security context appears wrong in /usr/lib64/bind
security context appears wrong in /usr/lib64/bind
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2010-02-17 14:41 EST by Matt Castelein
Modified: 2013-04-30 19:45 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-22 11:50:53 EST
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 Matt Castelein 2010-02-17 14:41:31 EST
Description of problem: Restorecon wants to make these files lib_t, but I believe they should stay named_conf_t:

restorecon reset /usr/lib64/bind context system_u:object_r:named_conf_t:s0->system_u:object_r:lib_t:s0

Version-Release number of selected component (if applicable):
Comment 1 Daniel Walsh 2010-02-17 15:25:32 EST
Why do you think this?  What goes into this directory?
Comment 2 Matt Castelein 2010-02-17 15:32:43 EST
the directory belongs to package bind-9.6.1-16.P3.fc12.x86_64, that is why I figure it was supposed to be named_conf_t, unless something has changed in an update and this context is a holdover from a previous release.
Comment 3 Daniel Walsh 2010-02-17 15:59:05 EST
No just because a package ships a directory does not mean it has to have specific labels associated with it.

In this case bind probably puts shared libraries in this directory, so we just leave it labeled the default label lib_t.

named_conf_t is for configuration data associated with the named_t domain.  If we labeled /usr/lib/bind as named_conf_t, the bind daemon (named_t) would not be allowed to execute the libraries.
Comment 4 Matt Castelein 2010-02-17 16:41:32 EST
Very well, but in that case I have no idea how it got labeled named_conf_t in the first place, because I didn't do it.
Comment 5 Daniel Walsh 2010-02-17 16:54:26 EST
Ok, in that case it might be a bug in named.

It should definitely not be labeled named_conf_t.
Comment 6 Daniel Walsh 2010-02-17 16:55:07 EST
I guess you need to check if a fresh install and after a bind-chroot install is this directory labeled lib_t.
Comment 7 Matt Castelein 2010-02-17 17:16:27 EST
This is a production machine I can't reload.. And I don't have any free x86_64 boxes at the moment to test with.. I tried it on a VM (i686) and /usr/lib/bind came out ok..  I will look for a 64-bit box to test on if no one else can test..
Comment 8 Adam Tkac 2010-02-22 11:50:53 EST
The /usr/lib{,64}/bind directory is location for BIND plugins (currently LDAP plugin from bind-dyndb-ldap package) so it should be definitely labelled as lib_t. I'm not sure how it got mislabelled on your system.

If you hit this problem again, please reopen this issue. Closing for now.

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