Daniel J Walsh wrote: > On 01/08/2013 05:12 PM, m.roth@xxxxxxxxx wrote: >> Daniel J Walsh wrote: >>> On 01/08/2013 05:04 PM, m.roth@xxxxxxxxx wrote: >>>> Daniel J Walsh wrote: >>>>> On 01/08/2013 01:57 PM, m.roth@xxxxxxxxx wrote: >>>>>> Is this a bug? It's certainly a real inconsistancy, IMO. >>>>>> >>>>>> I just built a user's workstation, new, as fc-17. >>>>>> >>>>>> ll -Z /usr/sbin/sshd -rwxr-xr-x. root root >>>>>> system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd* >>>>>> >>>>>> ll -Z /etc/ssh/ drwxr-xr-x. root root system_u:object_r:etc_t:s0 >>>>>> ./ drwxr-xr-x. root root system_u:object_r:etc_t:s0 ../ >>>>>> -rw-------. root root system_u:object_r:etc_t:s0 moduli >>>>>> -rw-r--r--. root root system_u:system_u:etc_t:s0 ssh_config >>>>>> -rw-------. root root system_u:system_u:etc_t:s0 sshd_config >>>>>> -rw-------. root root system_u:system_u:etc_t:s0 >>>>>> sshd_config.rpmnew -rw-------. root root >>>>>> system_u:system_u:sshd_key_t:s0 ssh_host_dsa_key -rw-r--r--. root >>>>>> root system_u:system_u:sshd_key_t:s0 ssh_host_dsa_key.pub >>>>>> -rw-------. root root system_u:system_u:sshd_key_t:s0 ssh_host_key >>>>>> -rw-r--r--. root root system_u:system_u:sshd_key_t:s0 >>>>>> ssh_host_key.pub -rw-------. root root >>>>>> system_u:system_u:sshd_key_t:s0 ssh_host_rsa_key -rw-r--r--. root >>>>>> root system_u:system_u:sshd_key_t:s0 ssh_host_rsa_key.pub >>>>>> -rw-r--r--. root root system_u:system_u:etc_t:s0 >>>>>> ssh_known_hosts >>>>>> >>>>>> sealert tells me that the ssh_host_*_key should be etc_t, not, as >>>>>> I set it, sshd_key_t. >>>>>> >>>>> What does matchpathcon /etc/ssh/ssh_host* >>>>> >>>>> Say? >>>> <snip> matchpathcon /etc/ssh/ssh_host* /etc/ssh/ssh_host_dsa_key >>>> system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host_dsa_key.pub >>>> system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host_key >>>> system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host_key.pub >>>> system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host_rsa_key >>>> system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host_rsa_key.pub >>>> system_u:object_r:sshd_key_t:s0 >>>> >>> can you attach the sealert message? >> >> SELinux is preventing /usr/sbin/sshd from getattr access on the file >> /etc/ssh/ss h_host_rsa_key. >> >> ***** Plugin restorecon (94.8 confidence) suggests >> ************************* >> >> If you want to fix the label. /etc/ssh/ssh_host_rsa_key default label >> should be etc_t. Then you can run restorecon. Do # /sbin/restorecon -v >> /etc/ssh/ssh_host_rsa_key >> >> ***** Plugin catchall_labels (5.21 confidence) suggests >> ******************** >> >> If you want to allow sshd to have getattr access on the ssh_host_rsa_key >> file Then you need to change the label on /etc/ssh/ssh_host_rsa_key Do # >> semanage fcontext -a -t FILE_TYPE '/etc/ssh/ssh_host_rsa_key' where >> FILE_TYPE is one of the following: oddjob_mkhomedir_exec_t, >> rpm_script_tmp >> _t, dbusd_etc_t, systemd_systemctl_exec_t, sshd_exec_t, >> fusermount_exec_t, >> secur ity_t, ld_so_cache_t, faillog_t, abrt_var_cache_t, pam_exec_t, >> lastlog_t, passwd _file_t, nx_server_home_ssh_t, proc_net_t, >> sosreport_tmp_t, machineid_t, rssh_ro _t, cfengine_var_log_t, >> proc_afs_t, >> krb5_conf_t, chkpwd_exec_t, rpm_tmp_t, etc_r untime_t, condor_var_lib_t, >> updpwd_exec_t, openct_var_run_t, abrt_var_run_t, user_home_type, >> configfile, initrc_var_run_t, domain, initrc_tmp_t, pcscd_var_run_t , >> samba_etc_t, sshd_var_run_t, user_cron_spool_t, pam_var_run_t, >> shutdown_exec_t , ssh_home_t, exec_type, sysctl_crypto_t, user_tmp_type, >> systemd_logind_var_run_ t, sysctl_kernel_t, samba_var_t, >> mount_ecryptfs_exec_t, local_login_home_t, syst em_dbusd_var_lib_t, >> samba_etc_t, systemd_logind_sessions_t, net_conf_t, user_tmp _t, >> selinux_config_t, logfile, gitosis_var_lib_t, sshd_tmpfs_t, >> openshift_tmp_t, default_context_t, mail_spool_t, rlogind_home_t, >> locale_t, nx_server_exec_t, va r_auth_t, cgroup_t, etc_t, ld_so_t, >> abrt_t, >> bin_t, proc_t, cert_t, sysfs_t, init _t, lib_t, user_home_t, >> krb5_keytab_t, >> sshd_t, usr_t, wtmp_t, cpu_online_t, abrt _helper_exec_t, user_tmp_t, >> login_exec_t, auth_home_t, sshd_keytab_t, xauth_exec _t, auth_cache_t, >> tmpfile, etc_t, selinux_login_config_t, ecryptfs_t, cert_t, pu >> ppet_tmp_t, >> screen_exec_t, fail2ban_var_lib_t, mount_exec_t, shell_exec_t, ssh_a >> gent_exec_t, textrel_shlib_t, krb5_home_t, passwd_exec_t, crack_db_t, >> rssh_exec_ t, ssh_home_t, sshd_key_t, krb5_conf_t, sssd_public_t, >> security_t, file_context_ t, root_t, krb5_host_rcache_t, nfs_t, >> krb5_host_rcache_t, shell_exec_t. Then execute: restorecon -v >> '/etc/ssh/ssh_host_rsa_key' >> >> >> ***** Plugin catchall (1.44 confidence) suggests >> *************************** >> >> If you believe that sshd should be allowed getattr access on the >> ssh_host_rsa_ke y file 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: # grep sshd /var/log/audit/audit.log | >> audit2allow -M mypol # semodule -i mypol.pp >> >> >> Additional Information: Source Context >> system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context >> system_u:object_r:unlabeled_t:s0 Target Objects >> /etc/ssh/ssh_host_rsa_key [ file ] Source sshd >> Source Path /usr/sbin/sshd Port >> <Unknown> Host example.com Source RPM Packages >> openssh-server-5.9p1-28.fc17.x86_64 Target RPM Packages Policy RPM >> selinux-policy-3.10.0-166.fc17.noarch Selinux Enabled True >> Policy Type targeted Enforcing Mode >> Permissive Host Name example.com Platform >> Linux example.com 3.6.11-1.fc17.x86_64 #1 SMP Mon Dec 17 22:16:35 UTC >> 2012 >> x86_64 x86_64 Alert Count 22 First Seen >> 2013-01-07 17:19:53 EST Last Seen 2013-01-08 >> 12:46:46 >> EST Local ID 99e7ca06-e6f8-4fe2-9440-13c11c062525 >> >> Raw Audit Messages type=AVC msg=audit(1357667206.325:709): avc: denied >> { >> getattr } for pid=3470 comm="sshd" path="/etc/ssh/ssh_host_rsa_key" >> dev="sda3" ino=11372820 scontext=sy >> stem_u:system_r:sshd_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:unlabeled_t:s0 tclass=file >> >> type=SYSCALL msg=audit(1357667206.325:709): arch=x86_64 syscall=fstat >> success=ye s exit=0 a0=3 a1=7fff34871680 a2=7fff34871680 a3=10 items=0 >> ppid=862 pid=3470 au id=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 >> egid=0 >> sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sshd exe=/usr/sbin/sshd >> subj=system_u:system_r:sshd_t:s0-s0 :c0.c1023 key=(null) Hash: >> sshd,sshd_t,unlabeled_t,file,getattr >> >> audit2allow >> >> #============= sshd_t ============== allow sshd_t unlabeled_t:file >> getattr; >> >> audit2allow -R >> >> #============= sshd_t ============== allow sshd_t unlabeled_t:file >> getattr; >> >> >> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/selinux >> > > Well it was correct about relabeling the file to something other then > unlabeled_t, but the alert saying it should be etc_t is broken. > Ok, so what's my best way to shut the sealert up: a local policy, or wait for a fixed policy? mark -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux