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
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
