Description of problem: SELinux is preventing (ostnamed) from 'mounton' accesses on the directory /dev. ***** Plugin restorecon (94.8 confidence) suggests ************************ If you want to fix the label. /dev default label should be device_t. Then you can run restorecon. Do # /sbin/restorecon -v /dev ***** Plugin catchall_labels (5.21 confidence) suggests ******************* If you want to allow (ostnamed) to have mounton access on the dev directory Then you need to change the label on /dev Do # semanage fcontext -a -t FILE_TYPE '/dev' where FILE_TYPE is one of the following: admin_home_t, anon_inodefs_t, audit_spool_t, auditd_log_t, autofs_t, automount_tmp_t, bacula_store_t, binfmt_misc_fs_t, boot_t, capifs_t, cgroup_t, cifs_t, container_image_t, debugfs_t, default_t, device_t, devpts_t, dnssec_t, dosfs_t, ecryptfs_t, efivarfs_t, fusefs_t, home_root_t, hugetlbfs_t, ifconfig_var_run_t, init_var_run_t, initrc_tmp_t, iso9660_t, kdbusfs_t, mail_spool_t, mnt_t, mqueue_spool_t, named_conf_t, news_spool_t, nfs_t, nfsd_fs_t, openshift_tmp_t, openshift_var_lib_t, oracleasmfs_t, proc_t, proc_xen_t, pstore_t, public_content_rw_t, public_content_t, ramfs_t, random_seed_t, removable_t, root_t, rpc_pipefs_t, security_t, spufs_t, src_t, svirt_sandbox_file_t, sysctl_fs_t, sysctl_t, sysfs_t, sysv_t, tmp_t, tmpfs_t, usbfs_t, user_home_dir_t, user_home_t, user_tmp_t, usr_t, var_lib_nfs_t, var_lib_t, var_lock_t, var_log_t, var_run_t, var_t, virt_image_t, virt_var_lib_t, vmblock_t, vxfs_t, xend_var_lib_t, xend_var_run_t, xenfs_t, xenstored_var_lib_t. Then execute: restorecon -v '/dev' ***** Plugin catchall (1.44 confidence) suggests ************************** If you believe that (ostnamed) should be allowed mounton access on the dev directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c '(ostnamed)' --raw | audit2allow -M my-ostnamed # semodule -X 300 -i my-ostnamed.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects /dev [ dir ] Source (ostnamed) Source Path (ostnamed) Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages filesystem-3.2-37.fc24.x86_64 Policy RPM selinux-policy-3.13.1-192.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 4.7.0-0.rc0.git10.1.fc25.x86_64 #1 SMP Fri May 27 14:56:48 UTC 2016 x86_64 x86_64 Alert Count 2 First Seen 2016-06-02 09:57:32 EDT Last Seen 2016-06-02 09:58:05 EDT Local ID a6cac58b-dd01-4f1b-b019-6eebe92a798e Raw Audit Messages type=AVC msg=audit(1464875885.85:264): avc: denied { mounton } for pid=1753 comm="(-localed)" path="/dev" dev="dm-0" ino=262657 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=1 Hash: (ostnamed),init_t,unlabeled_t,dir,mounton Version-Release number of selected component: selinux-policy-3.13.1-192.fc25.noarch Additional info: reporter: libreport-2.7.1 hashmarkername: setroubleshoot kernel: 4.7.0-0.rc0.git10.1.fc25.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
***** Plugin restorecon (94.8 confidence) suggests ************************ If you want to fix the label. /dev default label should be device_t. Then you can run restorecon. Do # /sbin/restorecon -Rv /dev
Description of problem: Appears on boot of current Rawhide Workstation live with enforcing=0 . If you attempt to boot without enforcing=0, the system never reaches the desktop. There are 3 other alerts, not sure which is the critical one. The others were related to accounts-daemon. Note that this is booting a clean live image, I've done nothing odd to /dev. Despite what the 'advisory' message says, if I do 'ls -ldZ /dev', I see system_u:object_r:device_t:s0 . Could be some kind of race? Version-Release number of selected component: selinux-policy-3.13.1-194.fc25.noarch Additional info: reporter: libreport-2.7.1 hashmarkername: setroubleshoot kernel: 4.7.0-0.rc2.git1.1.fc25.x86_64 reproducible: Not sure how to reproduce the problem type: libreport
*** This bug has been marked as a duplicate of bug 1347930 ***