Building a new LUKS encrypted device against a LVM lv causes some nontrivial denials. ( A continuation of #535992 under a different scenario ) # cryptsetup luksFormat /dev/server/squid /etc/squid.key WARNING! ======== This will overwrite data on /dev/server/squid irrevocably. Are you sure? (Type uppercase yes): YES device-mapper: remove ioctl on temporary-cryptsetup-13329 failed: Device or resource busy device-mapper: remove ioctl on temporary-cryptsetup-13329 failed: Device or resource busy --> Jan 8 01:54:58 testbed kernel: [29599.401604] audit: type=1400 audit(1420703698.125:1271): avc: denied { setattr } for pid=47 comm="kdevtmpfs" name="dm-7" dev="devtmpfs" ino=11356659 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:device_t tclass=blk_file permissive=1 Jan 8 01:54:58 testbed kernel: [29599.406696] audit: type=1400 audit(1420703698.130:1272): avc: denied { getattr } for pid=13329 comm="cryptsetup" name="/" dev="devtmpfs" ino=1025 ipaddr=173.173.113.156 scontext=root:sysadm_r:lvm_t tcontext=system_u:object_r:device_t tclass=filesystem permissive=1 Jan 8 01:54:58 testbed kernel: [29599.616950] audit: type=1400 audit(1420703698.340:1273): avc: denied { getattr } for pid=47 comm="kdevtmpfs" path="/dm-7" dev="devtmpfs" ino=11356659 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file permissive=1 Jan 8 01:54:58 testbed kernel: [29599.616970] audit: type=1400 audit(1420703698.340:1274): avc: denied { setattr } for pid=47 comm="kdevtmpfs" name="dm-7" dev="devtmpfs" ino=11356659 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file permissive=1 Jan 8 01:54:58 testbed kernel: [29599.616988] audit: type=1400 audit(1420703698.340:1275): avc: denied { unlink } for pid=47 comm="kdevtmpfs" name="dm-7" dev="devtmpfs" ino=11356659 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:fixed_disk_device_t tclass=blk_file permissive=1 The lvm_t getattr is solved easily with dev_getattr_generic_dirs(), but the fixed_disk_device_t stuff looks like it needs something like storage_raw_write_fixed_disk() which is not too surprising given that cryptsetup directly writes to the block device in order to format it. This does not only affect cryptfs formatting, but mounting as well.
The denials shown are taken with permissive mode on. Are they all needed for the command to function? I personally use LVM on top of encrypted PVs instead of vice-versa and haven't gotten this problem. The dm-7 one is currently marked as device_t according to your denials, where it should be fixed_disk_device_t. To resolve that, we need to see how the device is created and why it doesn't get the proper type associated. # ls -Z /dev/dm-1 system_u:object_r:fixed_disk_device_t:s0 /dev/dm-1
Without additional info there is little we can do right now. If you find the information, don't hesitate to reopen.
