After bootup: """ restorecon reset /dev/device-mapper context system_u:object_r:device_t->system_u:object_r:fixed_disk_device_t restorecon reset /dev/mapper/vg-var context system_u:object_r:device_t->system_u:object_r:fixed_disk_device_t restorecon reset /dev/mapper/vg-usr context system_u:object_r:device_t->system_u:object_r:fixed_disk_device_t restorecon reset /dev/mapper/vg-root context system_u:object_r:device_t->system_u:object_r:fixed_disk_device_t restorecon reset /dev/mapper/vg-opt context system_u:object_r:device_t->system_u:object_r:fixed_disk_device_t restorecon reset /dev/mapper/vg-home context system_u:object_r:device_t->system_u:object_r:fixed_disk_device_t """ These probably need to be set policy-wise. Reproducible: Always
Seems to be only when called from within the initramfs, as that all runs in the kernel_t domain.
The /dev/device-mapper one is now in policy. The other ones will be more difficult (if not impossible) with just policy changes as the names of the files are chosen by the user, and we cannot create a catch-all file transition. Hence, for /dev/mapper/* we need to wait and run a restorecon later.
Back to square 1, device-mapper is a character device, so the file transition won't work
18:06 <@SwifT> so either I do some overhauling on the policy, making /dev/mapper something like "mapper_device_t" and then have all block devices in mapper_device_t be marked as fixed_disk_device_t (but then all domains that need access to /dev/mapper need search or even list privileges on mapper_device_t + transition of the control file should be on mapper_device_t as well)... or we just have a restorecon on /dev... 18:06 <@SwifT> honestly, the restorecon sounds like a lot easier :p Guess we'll have to push /etc/init.d/selinux_gentoo more. I'll move this bug together with the stabilization of policycoreutils-2.1.13-r8 or higher
Stabilized
