abnormal SELinux context labels

abnormal SELinux context labels

[Bond Masuda]

[-- 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 --]

Re: abnormal SELinux context labels

[Simon Sekidde]

----- 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 

Re: abnormal SELinux context labels

[Bond Masuda]

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.

Re: abnormal SELinux context labels

[Simon Sekidde]

----- 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 

Re: abnormal SELinux context labels

[Bond Masuda]

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.
>>

Re: abnormal SELinux context labels

[Bond Masuda]

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.

Re: abnormal SELinux context labels

[Stephen Smalley]

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.

Re: abnormal SELinux context labels

[Bond Masuda]

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

Re: abnormal SELinux context labels

[Stephen Smalley]

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.