* abnormal SELinux context labels @ 2016-06-22 18:05 Bond Masuda 2016-06-22 18:22 ` Simon Sekidde 2016-06-22 18:54 ` Stephen Smalley 0 siblings, 2 replies; 9+ messages in thread From: Bond Masuda @ 2016-06-22 18:05 UTC (permalink / raw) To: selinux [-- Attachment #1: Type: text/plain, Size: 2649 bytes --] I'm installing CentOS 7 in a chroot'd environment to build new images of CentOS 7 for a private cloud environment. I've done this successfully before with CentOS 6 (with help from this list) and we have an automated process of doing that now. I'm now porting our process to do similarly for CentOS 7. However, after our process is complete, certain directories/symlinks have abnormal SELinux contexts assigned to them. This causes the system to fail to boot since we have SELinux enforcing by default and one of the problematic symlinks is /lib64. Here is what we see in the CentOS 7 build tree root directory, right after a fresh install of CentOS 7 from the full updates repo: |# ls -alZ / dr-xr-xr-x. root root system_u:object_r:root_t:s0 . dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home lrwxrwxrwx. root root /usr/lib lib -> usr/lib lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root drwxr-xr-x. root root /var/run run lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin drwxr-xr-x. root root system_u:object_r:var_t:s0 srv drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr drwxr-xr-x. root root system_u:object_r:var_t:s0 var |As you can see, the SELinux context for "lib", is "/usr/lib"!!! and similarly, for "lib64", it is "/usr/lib" ... those are not even valid context labels! How can an invalid string like "/usr/lib" even be assigned as a SELinux label in the first place? I can workaround this with a manual fix using 'chcon system_u:object_r:type_label:s0 path', but I'm just wondering how this can happen in the first place? When I try to manually reproduce the invalid label, I get this: # chcon /usr/lib lib chcon: invalid context: /usr/lib Any insights would be appreciated... Bond [-- Attachment #2: Type: text/html, Size: 3422 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:05 abnormal SELinux context labels Bond Masuda @ 2016-06-22 18:22 ` Simon Sekidde 2016-06-22 18:28 ` Bond Masuda 2016-06-22 18:30 ` Simon Sekidde 2016-06-22 18:54 ` Stephen Smalley 1 sibling, 2 replies; 9+ messages in thread From: Simon Sekidde @ 2016-06-22 18:22 UTC (permalink / raw) To: Bond Masuda; +Cc: selinux ----- Original Message ----- > From: "Bond Masuda" <bond.masuda@jlbond.com> > To: selinux@tycho.nsa.gov > Sent: Wednesday, June 22, 2016 2:05:17 PM > Subject: abnormal SELinux context labels > > I'm installing CentOS 7 in a chroot'd environment to build new images of > CentOS 7 for a private cloud environment. I've done this successfully before > with CentOS 6 (with help from this list) and we have an automated process of > doing that now. I'm now porting our process to do similarly for CentOS 7. > However, after our process is complete, certain directories/symlinks have > abnormal SELinux contexts assigned to them. This causes the system to fail > to boot since we have SELinux enforcing by default and one of the > problematic symlinks is /lib64. > > Here is what we see in the CentOS 7 build tree root directory, right after a > fresh install of CentOS 7 from the full updates repo: > > # ls -alZ / > dr-xr-xr-x. root root system_u:object_r:root_t:s0 . > dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit > lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin > dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev > drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home > lrwxrwxrwx. root root /usr/lib lib -> usr/lib > lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 > drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media > drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt > drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc > dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root > drwxr-xr-x. root root /var/run run > lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin > drwxr-xr-x. root root system_u:object_r:var_t:s0 srv > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys > drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp > drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr > drwxr-xr-x. root root system_u:object_r:var_t:s0 var > > As you can see, the SELinux context for "lib", is "/usr/lib"!!! and > similarly, for "lib64", it is "/usr/lib" ... those are not even valid > context labels! > > How can an invalid string like "/usr/lib" even be assigned as a SELinux label > in the first place? > Its not the SELinux label but a symbolic link /lib is a symbolic link to /usr/lib /lib64 is a symbolic link to /usr/lib64 And both of which have the same type 'lib_t' $ matchpathcon /lib /lib64 > I can workaround this with a manual fix using 'chcon > system_u:object_r:type_label:s0 path', but I'm just wondering how this can > happen in the first place? When I try to manually reproduce the invalid > label, I get this: > > # chcon /usr/lib lib > chcon: invalid context: /usr/lib > > Any insights would be appreciated... > Bond > > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. -- Simon Sekidde * Red Hat, Inc. * Westford, MA gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:22 ` Simon Sekidde @ 2016-06-22 18:28 ` Bond Masuda 2016-06-22 18:30 ` Simon Sekidde 1 sibling, 0 replies; 9+ messages in thread From: Bond Masuda @ 2016-06-22 18:28 UTC (permalink / raw) To: Simon Sekidde; +Cc: selinux On 06/22/2016 11:22 AM, Simon Sekidde wrote: > > ----- Original Message ----- >> From: "Bond Masuda" <bond.masuda@jlbond.com> >> To: selinux@tycho.nsa.gov >> Sent: Wednesday, June 22, 2016 2:05:17 PM >> Subject: abnormal SELinux context labels >> >> I'm installing CentOS 7 in a chroot'd environment to build new images of >> CentOS 7 for a private cloud environment. I've done this successfully before >> with CentOS 6 (with help from this list) and we have an automated process of >> doing that now. I'm now porting our process to do similarly for CentOS 7. >> However, after our process is complete, certain directories/symlinks have >> abnormal SELinux contexts assigned to them. This causes the system to fail >> to boot since we have SELinux enforcing by default and one of the >> problematic symlinks is /lib64. >> >> Here is what we see in the CentOS 7 build tree root directory, right after a >> fresh install of CentOS 7 from the full updates repo: >> >> # ls -alZ / >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 . >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >> drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit >> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin >> dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot >> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev >> drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc >> drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home >> lrwxrwxrwx. root root /usr/lib lib -> usr/lib >> lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 >> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media >> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt >> drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt >> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc >> dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root >> drwxr-xr-x. root root /var/run run >> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin >> drwxr-xr-x. root root system_u:object_r:var_t:s0 srv >> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp >> drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr >> drwxr-xr-x. root root system_u:object_r:var_t:s0 var >> >> As you can see, the SELinux context for "lib", is "/usr/lib"!!! and >> similarly, for "lib64", it is "/usr/lib" ... those are not even valid >> context labels! >> >> How can an invalid string like "/usr/lib" even be assigned as a SELinux label >> in the first place? >> > Its not the SELinux label but a symbolic link > > /lib is a symbolic link to /usr/lib > /lib64 is a symbolic link to /usr/lib64 > > And both of which have the same type 'lib_t' > > $ matchpathcon /lib /lib64 > Hi Simon: Yes, i know they should have type "lib_t", but see above again... the label is actually "/usr/lib". The two examples of lib and lib64 are symlinks, but look above at the directory /run as well, which has label "/var/run". Furthermore, when I fix these labels manually, the CentOS 7 image boots up with SELinux enforcing; when I don't fix these labels, almost everything breaks. >> I can workaround this with a manual fix using 'chcon >> system_u:object_r:type_label:s0 path', but I'm just wondering how this can >> happen in the first place? When I try to manually reproduce the invalid >> label, I get this: >> >> # chcon /usr/lib lib >> chcon: invalid context: /usr/lib >> >> Any insights would be appreciated... >> Bond >> >> >> _______________________________________________ >> Selinux mailing list >> Selinux@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to >> Selinux-request@tycho.nsa.gov. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:22 ` Simon Sekidde 2016-06-22 18:28 ` Bond Masuda @ 2016-06-22 18:30 ` Simon Sekidde 2016-06-22 18:35 ` Bond Masuda 1 sibling, 1 reply; 9+ messages in thread From: Simon Sekidde @ 2016-06-22 18:30 UTC (permalink / raw) To: Bond Masuda; +Cc: selinux ----- Original Message ----- > From: "Simon Sekidde" <ssekidde@redhat.com> > To: "Bond Masuda" <bond.masuda@jlbond.com> > Cc: selinux@tycho.nsa.gov > Sent: Wednesday, June 22, 2016 2:22:18 PM > Subject: Re: abnormal SELinux context labels > > > > ----- Original Message ----- > > From: "Bond Masuda" <bond.masuda@jlbond.com> > > To: selinux@tycho.nsa.gov > > Sent: Wednesday, June 22, 2016 2:05:17 PM > > Subject: abnormal SELinux context labels > > > > I'm installing CentOS 7 in a chroot'd environment to build new images of > > CentOS 7 for a private cloud environment. I've done this successfully > > before > > with CentOS 6 (with help from this list) and we have an automated process > > of > > doing that now. I'm now porting our process to do similarly for CentOS 7. > > However, after our process is complete, certain directories/symlinks have > > abnormal SELinux contexts assigned to them. This causes the system to fail > > to boot since we have SELinux enforcing by default and one of the > > problematic symlinks is /lib64. > > > > Here is what we see in the CentOS 7 build tree root directory, right after > > a > > fresh install of CentOS 7 from the full updates repo: > > > > # ls -alZ / > > dr-xr-xr-x. root root system_u:object_r:root_t:s0 . > > dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > > drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit > > lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin > > dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot > > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev > > drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc > > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home > > lrwxrwxrwx. root root /usr/lib lib -> usr/lib > > lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 > > drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media > > drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt > > drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt > > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc > > dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root > > drwxr-xr-x. root root /var/run run > > lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin > > drwxr-xr-x. root root system_u:object_r:var_t:s0 srv > > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys > > drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp > > drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr > > drwxr-xr-x. root root system_u:object_r:var_t:s0 var > > > > As you can see, the SELinux context for "lib", is "/usr/lib"!!! and > > similarly, for "lib64", it is "/usr/lib" ... those are not even valid > > context labels! > > Taking a closer look, is Is /usr on a separate partition? > > How can an invalid string like "/usr/lib" even be assigned as a SELinux > > label > > in the first place? > > > > Its not the SELinux label but a symbolic link > > /lib is a symbolic link to /usr/lib > /lib64 is a symbolic link to /usr/lib64 > > And both of which have the same type 'lib_t' > > $ matchpathcon /lib /lib64 > > > I can workaround this with a manual fix using 'chcon > > system_u:object_r:type_label:s0 path', but I'm just wondering how this can > > happen in the first place? When I try to manually reproduce the invalid > > label, I get this: > > > > # chcon /usr/lib lib > > chcon: invalid context: /usr/lib > > > > Any insights would be appreciated... > > Bond > > > > > > _______________________________________________ > > Selinux mailing list > > Selinux@tycho.nsa.gov > > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > > To get help, send an email containing "help" to > > Selinux-request@tycho.nsa.gov. > > -- > Simon Sekidde * Red Hat, Inc. * Westford, MA > gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. > -- Simon Sekidde * Red Hat, Inc. * Westford, MA gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:30 ` Simon Sekidde @ 2016-06-22 18:35 ` Bond Masuda 2016-06-22 18:53 ` Bond Masuda 0 siblings, 1 reply; 9+ messages in thread From: Bond Masuda @ 2016-06-22 18:35 UTC (permalink / raw) To: Simon Sekidde; +Cc: selinux On 06/22/2016 11:30 AM, Simon Sekidde wrote: > > ----- Original Message ----- >> From: "Simon Sekidde" <ssekidde@redhat.com> >> To: "Bond Masuda" <bond.masuda@jlbond.com> >> Cc: selinux@tycho.nsa.gov >> Sent: Wednesday, June 22, 2016 2:22:18 PM >> Subject: Re: abnormal SELinux context labels >> >> >> >> ----- Original Message ----- >>> From: "Bond Masuda" <bond.masuda@jlbond.com> >>> To: selinux@tycho.nsa.gov >>> Sent: Wednesday, June 22, 2016 2:05:17 PM >>> Subject: abnormal SELinux context labels >>> >>> I'm installing CentOS 7 in a chroot'd environment to build new images of >>> CentOS 7 for a private cloud environment. I've done this successfully >>> before >>> with CentOS 6 (with help from this list) and we have an automated process >>> of >>> doing that now. I'm now porting our process to do similarly for CentOS 7. >>> However, after our process is complete, certain directories/symlinks have >>> abnormal SELinux contexts assigned to them. This causes the system to fail >>> to boot since we have SELinux enforcing by default and one of the >>> problematic symlinks is /lib64. >>> >>> Here is what we see in the CentOS 7 build tree root directory, right after >>> a >>> fresh install of CentOS 7 from the full updates repo: >>> >>> # ls -alZ / >>> dr-xr-xr-x. root root system_u:object_r:root_t:s0 . >>> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >>> drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit >>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin >>> dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot >>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev >>> drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc >>> drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home >>> lrwxrwxrwx. root root /usr/lib lib -> usr/lib >>> lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 >>> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media >>> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt >>> drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt >>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc >>> dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root >>> drwxr-xr-x. root root /var/run run >>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin >>> drwxr-xr-x. root root system_u:object_r:var_t:s0 srv >>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys >>> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp >>> drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr >>> drwxr-xr-x. root root system_u:object_r:var_t:s0 var >>> >>> As you can see, the SELinux context for "lib", is "/usr/lib"!!! and >>> similarly, for "lib64", it is "/usr/lib" ... those are not even valid >>> context labels! >>> > Taking a closer look, is Is /usr on a separate partition? No, /usr is not on separate partition. Here's the partition scheme: /dev/mapper/vg_system-lv_root -> / /dev/mapper/loop0p1 -> /boot /dev/mapper/vg_system-lv_audit -> /audit /dev/mapper/vg_system-lv_home -> /home /dev/mapper/vg_system-lv_tmp -> /tmp /dev/mapper/vg_system-lv_var -> /var /dev/mapper/vg_system-lv_var_log -> /var/log This is a disk image mounted via loopback, and we use LVM2. Thanks for looking at it again... >>> How can an invalid string like "/usr/lib" even be assigned as a SELinux >>> label >>> in the first place? >>> >> Its not the SELinux label but a symbolic link >> >> /lib is a symbolic link to /usr/lib >> /lib64 is a symbolic link to /usr/lib64 >> >> And both of which have the same type 'lib_t' >> >> $ matchpathcon /lib /lib64 >> >>> I can workaround this with a manual fix using 'chcon >>> system_u:object_r:type_label:s0 path', but I'm just wondering how this can >>> happen in the first place? When I try to manually reproduce the invalid >>> label, I get this: >>> >>> # chcon /usr/lib lib >>> chcon: invalid context: /usr/lib >>> >>> Any insights would be appreciated... >>> Bond >>> >>> >>> _______________________________________________ >>> Selinux mailing list >>> Selinux@tycho.nsa.gov >>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>> To get help, send an email containing "help" to >>> Selinux-request@tycho.nsa.gov. >> -- >> Simon Sekidde * Red Hat, Inc. * Westford, MA >> gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E >> >> _______________________________________________ >> Selinux mailing list >> Selinux@tycho.nsa.gov >> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >> To get help, send an email containing "help" to >> Selinux-request@tycho.nsa.gov. >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:35 ` Bond Masuda @ 2016-06-22 18:53 ` Bond Masuda 0 siblings, 0 replies; 9+ messages in thread From: Bond Masuda @ 2016-06-22 18:53 UTC (permalink / raw) To: selinux To add some more info, I did a search for SELinux labels that include "/" and found some more mislabels: # find . -context \*/\* ./etc/systemd/system ./usr/lib64 ./usr/local/lib64 ./run/lock # ls -lZd ./etc/systemd/system ./usr/lib64 ./usr/local/lib64/ ./run/lock drwxr-xr-x. 9 root root /usr/lib/systemd/system 4096 Jun 21 16:10 ./etc/systemd/system drwxr-xr-x. 5 root root /var/lock 46 Jun 21 16:08 ./run/lock dr-xr-xr-x. 47 root root /usr/lib 32768 Jun 21 16:09 ./usr/lib64 drwxr-xr-x. 2 root root /usr/lib 6 Aug 12 2015 ./usr/local/lib64/ strange... On 06/22/2016 11:35 AM, Bond Masuda wrote: > > > On 06/22/2016 11:30 AM, Simon Sekidde wrote: >> >> ----- Original Message ----- >>> From: "Simon Sekidde" <ssekidde@redhat.com> >>> To: "Bond Masuda" <bond.masuda@jlbond.com> >>> Cc: selinux@tycho.nsa.gov >>> Sent: Wednesday, June 22, 2016 2:22:18 PM >>> Subject: Re: abnormal SELinux context labels >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Bond Masuda" <bond.masuda@jlbond.com> >>>> To: selinux@tycho.nsa.gov >>>> Sent: Wednesday, June 22, 2016 2:05:17 PM >>>> Subject: abnormal SELinux context labels >>>> >>>> I'm installing CentOS 7 in a chroot'd environment to build new >>>> images of >>>> CentOS 7 for a private cloud environment. I've done this successfully >>>> before >>>> with CentOS 6 (with help from this list) and we have an automated >>>> process >>>> of >>>> doing that now. I'm now porting our process to do similarly for >>>> CentOS 7. >>>> However, after our process is complete, certain >>>> directories/symlinks have >>>> abnormal SELinux contexts assigned to them. This causes the system >>>> to fail >>>> to boot since we have SELinux enforcing by default and one of the >>>> problematic symlinks is /lib64. >>>> >>>> Here is what we see in the CentOS 7 build tree root directory, >>>> right after >>>> a >>>> fresh install of CentOS 7 from the full updates repo: >>>> >>>> # ls -alZ / >>>> dr-xr-xr-x. root root system_u:object_r:root_t:s0 . >>>> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >>>> drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit >>>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin >>>> dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot >>>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev >>>> drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc >>>> drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home >>>> lrwxrwxrwx. root root /usr/lib lib -> usr/lib >>>> lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 >>>> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media >>>> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt >>>> drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt >>>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc >>>> dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root >>>> drwxr-xr-x. root root /var/run run >>>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin >>>> drwxr-xr-x. root root system_u:object_r:var_t:s0 srv >>>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys >>>> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp >>>> drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr >>>> drwxr-xr-x. root root system_u:object_r:var_t:s0 var >>>> >>>> As you can see, the SELinux context for "lib", is "/usr/lib"!!! and >>>> similarly, for "lib64", it is "/usr/lib" ... those are not even valid >>>> context labels! >>>> >> Taking a closer look, is Is /usr on a separate partition? > No, /usr is not on separate partition. Here's the partition scheme: > > /dev/mapper/vg_system-lv_root -> / > /dev/mapper/loop0p1 -> /boot > /dev/mapper/vg_system-lv_audit -> /audit > /dev/mapper/vg_system-lv_home -> /home > /dev/mapper/vg_system-lv_tmp -> /tmp > /dev/mapper/vg_system-lv_var -> /var > /dev/mapper/vg_system-lv_var_log -> /var/log > > This is a disk image mounted via loopback, and we use LVM2. Thanks for > looking at it again... > >>>> How can an invalid string like "/usr/lib" even be assigned as a >>>> SELinux >>>> label >>>> in the first place? >>>> >>> Its not the SELinux label but a symbolic link >>> >>> /lib is a symbolic link to /usr/lib >>> /lib64 is a symbolic link to /usr/lib64 >>> >>> And both of which have the same type 'lib_t' >>> >>> $ matchpathcon /lib /lib64 >>> >>>> I can workaround this with a manual fix using 'chcon >>>> system_u:object_r:type_label:s0 path', but I'm just wondering how >>>> this can >>>> happen in the first place? When I try to manually reproduce the >>>> invalid >>>> label, I get this: >>>> >>>> # chcon /usr/lib lib >>>> chcon: invalid context: /usr/lib >>>> >>>> Any insights would be appreciated... >>>> Bond >>>> >>>> >>>> _______________________________________________ >>>> Selinux mailing list >>>> Selinux@tycho.nsa.gov >>>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>>> To get help, send an email containing "help" to >>>> Selinux-request@tycho.nsa.gov. >>> -- >>> Simon Sekidde * Red Hat, Inc. * Westford, MA >>> gpg: 5848 958E 73BA 04D3 7C06 F096 1BA1 2DBF 94BC 377E >>> >>> _______________________________________________ >>> Selinux mailing list >>> Selinux@tycho.nsa.gov >>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>> To get help, send an email containing "help" to >>> Selinux-request@tycho.nsa.gov. >>> > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:05 abnormal SELinux context labels Bond Masuda 2016-06-22 18:22 ` Simon Sekidde @ 2016-06-22 18:54 ` Stephen Smalley 2016-06-22 19:05 ` Bond Masuda 1 sibling, 1 reply; 9+ messages in thread From: Stephen Smalley @ 2016-06-22 18:54 UTC (permalink / raw) To: Bond Masuda, selinux On 06/22/2016 02:05 PM, Bond Masuda wrote: > I'm installing CentOS 7 in a chroot'd environment to build new images of > CentOS 7 for a private cloud environment. I've done this successfully > before with CentOS 6 (with help from this list) and we have an automated > process of doing that now. I'm now porting our process to do similarly > for CentOS 7. However, after our process is complete, certain > directories/symlinks have abnormal SELinux contexts assigned to them. > This causes the system to fail to boot since we have SELinux enforcing > by default and one of the problematic symlinks is /lib64. > > Here is what we see in the CentOS 7 build tree root directory, right > after a fresh install of CentOS 7 from the full updates repo: > > |# ls -alZ / > dr-xr-xr-x. root root system_u:object_r:root_t:s0 . > dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. > drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit > lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin > dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev > drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home > lrwxrwxrwx. root root /usr/lib lib -> usr/lib > lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 > drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media > drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt > drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc > dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root > drwxr-xr-x. root root /var/run run > lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin > drwxr-xr-x. root root system_u:object_r:var_t:s0 srv > drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys > drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp > drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr > drwxr-xr-x. root root system_u:object_r:var_t:s0 var > > |As you can see, the SELinux context for "lib", is "/usr/lib"!!! and > similarly, for "lib64", it is "/usr/lib" ... those are not even valid > context labels! > > How can an invalid string like "/usr/lib" even be assigned as a SELinux > label in the first place? > > I can workaround this with a manual fix using 'chcon > system_u:object_r:type_label:s0 path', but I'm just wondering how this > can happen in the first place? When I try to manually reproduce the > invalid label, I get this: > > # chcon /usr/lib lib > chcon: invalid context: /usr/lib > > Any insights would be appreciated... > Bond I'm assuming you are running the labeling process in a domain that has CAP_MAC_ADMIN and mac_admin in SELinux policy, e.g. setfiles_mac_t or livecd_t. You would have done that in order to allow it to set labels on files that may not be defined in the build host policy. A process with that permission can set any arbitrary string value it wants as the security.selinux attribute; by design, SELinux on the build host OS will ignore it and just treat it as if it has the unlabeled context. So if there is a bug in your labeling program such that it is passing a pathname rather than a label, then you would get the results you are seeing. When you try to do it by hand above, you are presumably not running in a domain with mac_admin permission, and therefore it won't let you set an unknown value. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 18:54 ` Stephen Smalley @ 2016-06-22 19:05 ` Bond Masuda 2016-06-23 13:56 ` Stephen Smalley 0 siblings, 1 reply; 9+ messages in thread From: Bond Masuda @ 2016-06-22 19:05 UTC (permalink / raw) To: Stephen Smalley, selinux On 06/22/2016 11:54 AM, Stephen Smalley wrote: > On 06/22/2016 02:05 PM, Bond Masuda wrote: >> I'm installing CentOS 7 in a chroot'd environment to build new images of >> CentOS 7 for a private cloud environment. I've done this successfully >> before with CentOS 6 (with help from this list) and we have an automated >> process of doing that now. I'm now porting our process to do similarly >> for CentOS 7. However, after our process is complete, certain >> directories/symlinks have abnormal SELinux contexts assigned to them. >> This causes the system to fail to boot since we have SELinux enforcing >> by default and one of the problematic symlinks is /lib64. >> >> Here is what we see in the CentOS 7 build tree root directory, right >> after a fresh install of CentOS 7 from the full updates repo: >> >> |# ls -alZ / >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 . >> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >> drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit >> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin >> dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot >> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev >> drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc >> drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home >> lrwxrwxrwx. root root /usr/lib lib -> usr/lib >> lrwxrwxrwx. root root /usr/lib lib64 -> usr/lib64 >> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media >> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt >> drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt >> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc >> dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root >> drwxr-xr-x. root root /var/run run >> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin >> drwxr-xr-x. root root system_u:object_r:var_t:s0 srv >> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys >> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp >> drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr >> drwxr-xr-x. root root system_u:object_r:var_t:s0 var >> >> |As you can see, the SELinux context for "lib", is "/usr/lib"!!! and >> similarly, for "lib64", it is "/usr/lib" ... those are not even valid >> context labels! >> >> How can an invalid string like "/usr/lib" even be assigned as a SELinux >> label in the first place? >> >> I can workaround this with a manual fix using 'chcon >> system_u:object_r:type_label:s0 path', but I'm just wondering how this >> can happen in the first place? When I try to manually reproduce the >> invalid label, I get this: >> >> # chcon /usr/lib lib >> chcon: invalid context: /usr/lib >> >> Any insights would be appreciated... >> Bond > I'm assuming you are running the labeling process in a domain that has > CAP_MAC_ADMIN and mac_admin in SELinux policy, e.g. setfiles_mac_t or > livecd_t. > > You would have done that in order to allow it to set labels on files > that may not be defined in the build host policy. > > A process with that permission can set any arbitrary string value it > wants as the security.selinux attribute; by design, SELinux on the build > host OS will ignore it and just treat it as if it has the unlabeled context. > > So if there is a bug in your labeling program such that it is passing a > pathname rather than a label, then you would get the results you are seeing. > > When you try to do it by hand above, you are presumably not running in a > domain with mac_admin permission, and therefore it won't let you set an > unknown value. > > Hi Stephen, You are correct, and I guess that explains why the invalid labels can be set. Thank you for pointing that out. Here is the process we use to set the labels: 1. semanage permissive -a setfiles_mac_t 2. runcon -t setfiles_mac_t -- chroot /var/tmp/buildroot /sbin/setfiles -v -F -e /proc -e /sys -e /dev -e /selinux /etc/selinux/targeted/contexts/files/<some_fcontext_file> /path_to_filesystem. The above is iterated through each fcontext file and each file system. 3. semanage permissive -d setfiles_mac_t So, do you think this is a problem with the version of setfiles in CentOS7 or perhaps bad input from one of the fcontext files? Also, should it matter, the "host" is Fedora 23 Linux. Thanks, Bond ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: abnormal SELinux context labels 2016-06-22 19:05 ` Bond Masuda @ 2016-06-23 13:56 ` Stephen Smalley 0 siblings, 0 replies; 9+ messages in thread From: Stephen Smalley @ 2016-06-23 13:56 UTC (permalink / raw) To: Bond Masuda, selinux On 06/22/2016 03:05 PM, Bond Masuda wrote: > > > On 06/22/2016 11:54 AM, Stephen Smalley wrote: >> On 06/22/2016 02:05 PM, Bond Masuda wrote: >>> I'm installing CentOS 7 in a chroot'd environment to build new images of >>> CentOS 7 for a private cloud environment. I've done this successfully >>> before with CentOS 6 (with help from this list) and we have an automated >>> process of doing that now. I'm now porting our process to do similarly >>> for CentOS 7. However, after our process is complete, certain >>> directories/symlinks have abnormal SELinux contexts assigned to them. >>> This causes the system to fail to boot since we have SELinux enforcing >>> by default and one of the problematic symlinks is /lib64. >>> >>> Here is what we see in the CentOS 7 build tree root directory, right >>> after a fresh install of CentOS 7 from the full updates repo: >>> >>> |# ls -alZ / >>> dr-xr-xr-x. root root system_u:object_r:root_t:s0 . >>> dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. >>> drwxr-xr-x. root root system_u:object_r:auditd_log_t:s0 audit >>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 bin -> usr/bin >>> dr-xr-xr-x. root root system_u:object_r:boot_t:s0 boot >>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 dev >>> drwxr-xr-x. root root system_u:object_r:etc_t:s0 etc >>> drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home >>> lrwxrwxrwx. root root /usr/lib lib -> usr/lib >>> lrwxrwxrwx. root root /usr/lib lib64 -> >>> usr/lib64 >>> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 media >>> drwxr-xr-x. root root system_u:object_r:mnt_t:s0 mnt >>> drwxr-xr-x. root root system_u:object_r:usr_t:s0 opt >>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 proc >>> dr-xr-x---. root root system_u:object_r:admin_home_t:s0 root >>> drwxr-xr-x. root root /var/run run >>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0 sbin -> usr/sbin >>> drwxr-xr-x. root root system_u:object_r:var_t:s0 srv >>> drwxr-xr-x. root root unconfined_u:object_r:unlabeled_t:s0 sys >>> drwxrwxrwt. root root system_u:object_r:tmp_t:s0 tmp >>> drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr >>> drwxr-xr-x. root root system_u:object_r:var_t:s0 var >>> >>> |As you can see, the SELinux context for "lib", is "/usr/lib"!!! and >>> similarly, for "lib64", it is "/usr/lib" ... those are not even valid >>> context labels! >>> >>> How can an invalid string like "/usr/lib" even be assigned as a SELinux >>> label in the first place? >>> >>> I can workaround this with a manual fix using 'chcon >>> system_u:object_r:type_label:s0 path', but I'm just wondering how this >>> can happen in the first place? When I try to manually reproduce the >>> invalid label, I get this: >>> >>> # chcon /usr/lib lib >>> chcon: invalid context: /usr/lib >>> >>> Any insights would be appreciated... >>> Bond >> I'm assuming you are running the labeling process in a domain that has >> CAP_MAC_ADMIN and mac_admin in SELinux policy, e.g. setfiles_mac_t or >> livecd_t. >> >> You would have done that in order to allow it to set labels on files >> that may not be defined in the build host policy. >> >> A process with that permission can set any arbitrary string value it >> wants as the security.selinux attribute; by design, SELinux on the build >> host OS will ignore it and just treat it as if it has the unlabeled >> context. >> >> So if there is a bug in your labeling program such that it is passing a >> pathname rather than a label, then you would get the results you are >> seeing. >> >> When you try to do it by hand above, you are presumably not running in a >> domain with mac_admin permission, and therefore it won't let you set an >> unknown value. >> >> > Hi Stephen, > > You are correct, and I guess that explains why the invalid labels can be > set. Thank you for pointing that out. > > Here is the process we use to set the labels: > > 1. semanage permissive -a setfiles_mac_t > 2. runcon -t setfiles_mac_t -- chroot /var/tmp/buildroot /sbin/setfiles > -v -F -e /proc -e /sys -e /dev -e /selinux > /etc/selinux/targeted/contexts/files/<some_fcontext_file> > /path_to_filesystem. > > The above is iterated through each fcontext file and each file system. > 3. semanage permissive -d setfiles_mac_t > > So, do you think this is a problem with the version of setfiles in > CentOS7 or perhaps bad input from one of the fcontext files? > > Also, should it matter, the "host" is Fedora 23 Linux. I would guess bad input from the file_contexts files; that is what I would check first. setfiles -c /path/to/policy /path/to/file_contexts will validate them. If not, then it seems like a bad bug in setfiles; maybe run it under valgrind and look for a memory corruption error. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-06-23 13:56 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-22 18:05 abnormal SELinux context labels Bond Masuda 2016-06-22 18:22 ` Simon Sekidde 2016-06-22 18:28 ` Bond Masuda 2016-06-22 18:30 ` Simon Sekidde 2016-06-22 18:35 ` Bond Masuda 2016-06-22 18:53 ` Bond Masuda 2016-06-22 18:54 ` Stephen Smalley 2016-06-22 19:05 ` Bond Masuda 2016-06-23 13:56 ` Stephen Smalley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.