Bug 781840 - inconsistent labeling of /var/named/chroot/usr/lib/bind and /usr/lib/bind
Summary: inconsistent labeling of /var/named/chroot/usr/lib/bind and /usr/lib/bind
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-15 16:42 UTC by Eddie Lania
Modified: 2013-02-14 02:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-14 02:01:18 UTC
Type: ---


Attachments (Terms of Use)

Description Eddie Lania 2012-01-15 16:42:05 UTC
Description of problem: I found that relabeling of /usr/lib/bind and /var/named/chroot/usr/lib/bind using restorecon produces different results:

/sbin/restorecon -v -v -R /usr/lib/bind
/sbin/restorecon reset /usr/lib/bind context system_u:object_r:named_conf_t:s0->system_u:object_r:lib_t:s0

/sbin/restorecon -v -v -R /var/named/chroot/usr/lib/bind
/sbin/restorecon reset /var/named/chroot/usr/lib/bind context system_u:object_r:lib_t:s0->system_u:object_r:named_conf_t:s0

And so I wonder now what the right selinux contexts should be.


Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.10.0-71.fc16.noarch


How reproducible: Always


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Miroslav Grepl 2012-01-16 08:23:06 UTC
If you execute

$ chcon -R -t lib_t /var/named/chroot/usr/lib/bind

does it work correctly?

Comment 2 Eddie Lania 2012-01-16 10:11:17 UTC
No:

[root@ls2ka ~]# chcon -R -t lib_t /var/named/chroot/usr/lib/bind

[root@ls2ka ~]# /sbin/restorecon -v -v -R /var/named/chroot/usr/lib/bind
/sbin/restorecon reset /var/named/chroot/usr/lib/bind context system_u:object_r:lib_t:s0->system_u:object_r:named_conf_t:s0

[root@ls2ka ~]# /sbin/restorecon -v -v -R /usr/lib/bind
/sbin/restorecon reset /usr/lib/bind context system_u:object_r:named_conf_t:s0->system_u:object_r:lib_t:s0

Comment 3 Miroslav Grepl 2012-01-16 13:05:34 UTC
I thought BIND. 

restorecon will fix the label because of chcon.

Comment 4 Eddie Lania 2012-01-16 16:42:39 UTC
Hi Miroslav,


/var/named/chroot/usr/lib/bind is hard linked from /usr/lib/bind during execution of named.

So, isn't it then supposed to be that it inherits the context of /usr/lib/bind?

If so, then why is a restorecon then changing it from object_r:lib_t to object_r:named_conf_t?

Regards,

Eddie.

Comment 5 Eddie Lania 2012-01-16 16:56:54 UTC
Miroslav,

Apparently, there's more wrong here:

The following is from the problematic system:

[root@ls2ka ~]# ls -lisa --lcontext /var/named/chroot/usr
total 12
1479933 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root  4096 Aug 11  2009 .
1480115 4 drwxr-x---. 6 system_u:object_r:named_conf_t:s0 root named 4096 Nov 16 20:26 ..
1480114 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root  4096 Aug 11  2009 lib
[root@ls2ka ~]# ls -lisa --lcontext /var/named/chroot/usr/lib
total 12
1480114 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root  4096 Aug 11  2009 .
1479933 4 drwxr-xr-x. 3 unconfined_u:object_r:named_conf_t:s0 root root  4096 Aug 11  2009 ..
1261316 4 drwxr-x---. 2 system_u:object_r:lib_t:s0       root named 4096 Nov 16 20:26 bind
[root@ls2ka ~]# ls -lisa --lcontext /var/named
total 24
1480100 4 drwxr-x---.  6 system_u:object_r:named_zone_t:s0 root  named 4096 Dec 18 12:38 .
1267281 4 drwxr-xr-x. 25 system_u:object_r:var_t:s0       root  root  4096 Jan 10 10:09 ..
1480115 4 drwxr-x---.  6 system_u:object_r:named_conf_t:s0 root  named 4096 Nov 16 20:26 chroot
1480101 4 drwxrwx---.  2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 data
1480102 4 drwxrwx---.  2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 dynamic
1480107 4 drwxrwx---.  2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 slaves
[root@ls2ka ~]#

And from another system that has just been freshly installed:

[root@zeus ~]# ls -lisa --lcontext /var/named/chroot/usr
total 12
919084 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root  4096 Dec 10 20:29 .
919081 4 drwxr-x---. 6 system_u:object_r:named_conf_t:s0 root named 4096 Dec 10 20:29 ..
919085 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root  4096 Dec 10 20:29 lib64
[root@zeus ~]# ls -lisa --lcontext /var/named/chroot/usr/lib64/
total 12
 919085 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root 4096 Dec 10 20:29 .
 919084 4 drwxr-xr-x. 3 system_u:object_r:named_conf_t:s0 root root 4096 Dec 10 20:29 ..
3287094 4 drwxr-xr-x. 2 system_u:object_r:lib_t:s0       root root 4096 Nov 16 20:26 bind
[root@zeus ~]# ls -lisa --lcontext /var/named
total 24
657133 4 drwxr-x---.  6 system_u:object_r:named_zone_t:s0 root  named 4096 Dec 17 15:52 .
655361 4 drwxr-xr-x. 22 system_u:object_r:var_t:s0       root  root  4096 Dec 13 14:02 ..
919081 4 drwxr-x---.  6 system_u:object_r:named_conf_t:s0 root  named 4096 Dec 10 20:29 chroot
657134 4 drwxrwx---.  2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 data
788227 4 drwxrwx---.  2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 dynamic
919080 4 drwxrwx---.  2 system_u:object_r:named_cache_t:s0 named named 4096 Nov 16 20:26 slaves
[root@zeus ~]#

The first system has been updated from fc14 to fc16.

Can you tell me what is wrong and how I should correct it?

Thank you.

Regards,

Eddie.

Comment 6 Miroslav Grepl 2012-01-17 11:53:50 UTC
(In reply to comment #4)
> Hi Miroslav,
> 
> 
> /var/named/chroot/usr/lib/bind is hard linked from /usr/lib/bind during
> execution of named.
> 
> So, isn't it then supposed to be that it inherits the context of /usr/lib/bind?
> 
> If so, then why is a restorecon then changing it from object_r:lib_t to
> object_r:named_conf_t?
> 
> Regards,
> 
> Eddie.

This is a problem with hardlinks. We need to have the same label for both location.

Comment 7 Miroslav Grepl 2012-01-17 11:54:42 UTC
I will fix this labeling.

Comment 8 Fedora End Of Life 2013-02-14 02:01:22 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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