ref. bug 1423018

We need to see SELinux denials in the raw form. Could you attach the output of following command?

# ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

Thanks.

Created attachment 1255867 [details]
Information as requested

Here is the ausearch output (see comment#5) processed by audit2allow:

#============= targetd_t ==============

#!!!! This avc is allowed in the current policy
allow targetd_t bin_t:file { execute execute_no_trans };
allow targetd_t configfs_t:dir { add_name create getattr open read remove_name rmdir search write };
allow targetd_t configfs_t:file { getattr open read write };
allow targetd_t configfs_t:lnk_file { create getattr read unlink };

#!!!! WARNING: 'default_t' is a base type.
allow targetd_t default_t:dir { ioctl read };
allow targetd_t exports_t:file { getattr open read };
allow targetd_t fixed_disk_device_t:blk_file write;
allow targetd_t fs_t:filesystem getattr;
allow targetd_t insmod_exec_t:file getattr;
allow targetd_t kernel_t:system ipc_info;

#!!!! This avc can be allowed using the boolean 'domain_kernel_load_modules'
allow targetd_t kernel_t:system module_request;
allow targetd_t lvm_metadata_t:dir { add_name read remove_name write };
allow targetd_t lvm_metadata_t:file { append create link rename unlink };
allow targetd_t lvm_var_run_t:fifo_file { getattr lock open read write };
allow targetd_t modules_conf_t:dir { getattr open read };
allow targetd_t modules_conf_t:file { getattr open read };
allow targetd_t modules_object_t:dir search;
allow targetd_t modules_object_t:file { getattr open read };
allow targetd_t nfsd_fs_t:file { open read };

#!!!! This avc is allowed in the current policy
allow targetd_t self:capability sys_admin;
allow targetd_t self:capability { ipc_lock sys_nice };
allow targetd_t self:process setsched;

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow targetd_t self:tcp_socket accept;
allow targetd_t sysctl_rpc_t:dir search;
allow targetd_t sysctl_rpc_t:file { open read write };
allow targetd_t sysfs_t:file write;

#!!!! WARNING: 'unlabeled_t' is a base type.
allow targetd_t unlabeled_t:dir { ioctl read write };
allow targetd_t var_lib_nfs_t:dir { add_name remove_name write };
allow targetd_t var_lib_nfs_t:file { create getattr lock open read rename unlink write };

Above-mentioned output was generated on a machine where:

# rpm -qa selinux-policy\*
selinux-policy-targeted-3.13.1-144.el7.noarch
selinux-policy-devel-3.13.1-144.el7.noarch
selinux-policy-3.13.1-144.el7.noarch
#

Thank you for the AVC's, however it seems that your system has been running with disabled SELinux for some time and your security policy is outdated.

To get more accurate set of selinux denials please update selinux-policy-targeted package, run 
#restorecon -Rv /
to fix labels in your filesystem and re-run your use cases with SELinux in permissive mode.

Also it would be appreciated if you could go thorough the rules generated by audit2allow and make sure that all the access attempts make sense. Feel free to contact me if the meaning of the rules is unclear.

I've updated to policy files *.144.el7.noarch and run # restorecon -Rv /.  After doing this I ran some unit tests against targetd and got numerous errors.  Running audit2allow on the latest errors and loading those rules gets me runs without errors except for those associated with exportfs and btrfs commands which are executed in the targetd daemon.  I'll attach the te files generated by audit2allow for targetd and exportfs.

The final errors I'm getting with btrfs are likely a labeling issue.  Basically targetd allows you to take a btrfs and carve up sub volumes and take snapshots over the API.  When doing so SELinux is logging errors like:

SELinux is preventing /usr/sbin/btrfs from ioctl access on the directory /testing/targetd_ss/HRYV_fs_WXTR

Please note that the base btrfs directory is controllable by the user in the targetd config file, thus it could potentially be anywhere.

Please advise what the suggested context for a directory should be to create btrfs sub volumes and snapshots.

Created attachment 1274786 [details]
Autogenerated from audit2allow for exportfs

Created attachment 1274787 [details]
Autogenerated from audit2allow for targetd

Could you attach raw AVC msgs? 

Thanks, 
Lukas.

Created attachment 1275455 [details]
SELinux denials in the raw form

Collected with:

ausearch -m avc -m user_avc -m selinux_err -m user_selinux_err -i -ts today

I created a new 7.4 VM using the latest which includes:

selinux-policy-targeted-3.13.1-145.el7.noarch
selinux-policy-3.13.1-145.el7.noarch

to collect the latest selinux denials.

Could you re-run your scenario after installing the latest selinux-policy (3.13.1-164.el7)? Our automated TC indicates that following rules are missing but they might not be actually needed:

allow targetd_t insmod_exec_t : file { getattr };
allow targetd_t default_t : dir { ioctl read };
allow targetd_t lvm_var_run_t : fifo_file { open };

Things improving, but I'm still getting denials.  I spun up a new VM with nightly build which includes: 

selinux-policy-3.13.1-164.el7.noarch
selinux-policy-targeted-3.13.1-164.el7.noarch

I've attached the raw logs from this latest run.

The targetd daemon needs to be able to run the following commands:

btrfs
exportfs

I asked in comment #9 what the appropriate label should be for a mounted btrfs file system that the targetd service can run btrfs operations on, but didn't get a response to that.  I tried a couple different labels, but they all appeared to suffer the same fate of failed ioctls.

Created attachment 1290299 [details]
Latest SELinux denials

Switching to ASSIGNED based on SELinux denials attached in comment#30.

Created attachment 1292019 [details]
Raw denials with btrfs mounted to /mnt/targetd_fs

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0763