From: russell@coker.com.au (Russell Coker) Date: Mon, 06 Nov 2017 15:53:10 +1100 Subject: [refpolicy] [PATCH 2/2 v4] contrib: use the new SSL private keys type (was: "let the mozilla and other domains read generic SSL certificates") In-Reply-To: <1509921146.10385.3.camel@trentalancia.com> References: <1509848952.10522.10.camel@trentalancia.com> <1509908457.25895.0.camel@trentalancia.com> <1509921146.10385.3.camel@trentalancia.com> Message-ID: <40837600.Fp8dYYV2Cb@xev> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > diff -pru a/policy/modules/contrib/bind.te b/policy/modules/contrib/bind.te > --- a/policy/modules/contrib/bind.te 2017-09-29 19:01:55.131455647 +0200 > +++ b/policy/modules/contrib/bind.te 2017-11-05 22:16:02.480485341 +0100 > @@ -165,6 +165,7 @@ logging_send_syslog_msg(named_t) > > miscfiles_read_generic_certs(named_t) > miscfiles_read_localization(named_t) > +miscfiles_read_ssl_privkey(named_t) Why does it need this? Why would any type other than dnssec_t be used for actual private keys that named_t uses? I think that it was just granted such access in the past due to CA keys being inappropriately labeled. > diff -pru a/policy/modules/contrib/java.te b/policy/modules/contrib/java.te > --- a/policy/modules/contrib/java.te 2017-09-29 19:01:55.158455647 +0200 > +++ b/policy/modules/contrib/java.te 2017-11-05 21:52:29.634491117 +0100 > @@ -102,6 +103,7 @@ fs_dontaudit_rw_tmpfs_files(java_domain) > > logging_send_syslog_msg(java_domain) > > +miscfiles_read_generic_certs(java_domain) > miscfiles_read_localization(java_domain) > miscfiles_read_fonts(java_domain) Why? > diff -pru a/policy/modules/contrib/radius.te > b/policy/modules/contrib/radius.te --- > a/policy/modules/contrib/radius.te 2017-09-29 19:01:55.184455647 +0200 +++ > b/policy/modules/contrib/radius.te 2017-11-05 22:14:02.427485832 +0100 @@ > -111,6 +111,7 @@ logging_send_syslog_msg(radiusd_t) > > miscfiles_read_localization(radiusd_t) > miscfiles_read_generic_certs(radiusd_t) > +miscfiles_read_ssl_privkey(radiusd_t) > > sysnet_use_ldap(radiusd_t) The RADIUS protocol didn't use SSL private keys last time I implemented it. I expect that previous access would have been due to a RADIUS server talking to an LDAP backend or someother backend that used SSL. > diff -pru a/policy/modules/contrib/rpc.te b/policy/modules/contrib/rpc.te > --- a/policy/modules/contrib/rpc.te 2017-09-29 19:01:55.189455647 +0200 > +++ b/policy/modules/contrib/rpc.te 2017-11-05 22:06:48.316487607 +0100 > @@ -182,6 +182,7 @@ storage_getattr_fixed_disk_dev(rpcd_t) > selinux_dontaudit_read_fs(rpcd_t) > > miscfiles_read_generic_certs(rpcd_t) > +miscfiles_read_ssl_privkey(rpcd_t) > > seutil_dontaudit_search_config(rpcd_t) > What are these doing that requires SSL private key access? > @@ -316,6 +317,7 @@ files_dontaudit_write_var_dirs(gssd_t) > auth_manage_cache(gssd_t) > > miscfiles_read_generic_certs(gssd_t) > +miscfiles_read_ssl_privkey(gssd_t) > > userdom_signal_all_users(gssd_t) Wouldn't it be better to have a separate type for kerberos keys? I presume that's the only reason gssd_t needs access to any keys. Maybe the same for rpcd_t. > diff -pru a/policy/modules/contrib/samba.te > b/policy/modules/contrib/samba.te --- > a/policy/modules/contrib/samba.te 2017-09-29 19:01:55.191455647 +0200 +++ > b/policy/modules/contrib/samba.te 2017-11-05 22:21:52.511483910 +0100 @@ > -943,6 +943,7 @@ logging_send_syslog_msg(winbind_t) > > miscfiles_read_localization(winbind_t) > miscfiles_read_generic_certs(winbind_t) > +miscfiles_read_ssl_privkey(winbind_t) > > userdom_dontaudit_use_unpriv_user_fds(winbind_t) > userdom_manage_user_home_content_dirs(winbind_t) How do keys work in Samba? Would samba_secrets_t be better for any keys that it needs? > b/policy/modules/contrib/squid.te --- > a/policy/modules/contrib/squid.te 2017-09-29 19:01:55.197455647 +0200 +++ > b/policy/modules/contrib/squid.te 2017-11-05 22:14:31.766485712 +0100 @@ > -185,6 +185,7 @@ logging_send_syslog_msg(squid_t) > > miscfiles_read_generic_certs(squid_t) > miscfiles_read_localization(squid_t) > +miscfiles_read_ssl_privkey(squid_t) Maybe a boolean for this with a default of off, this would be an unusual corner case for squid_t, if it really needs such things. > diff -pru a/policy/modules/contrib/virt.te b/policy/modules/contrib/virt.te > --- a/policy/modules/contrib/virt.te 2017-11-04 20:14:12.111932898 +0100 > +++ b/policy/modules/contrib/virt.te 2017-11-05 22:19:20.560484532 +0100 > @@ -681,6 +681,7 @@ auth_use_nsswitch(virtd_t) > miscfiles_read_localization(virtd_t) > miscfiles_read_generic_certs(virtd_t) > miscfiles_read_hwdata(virtd_t) > +miscfiles_read_ssl_privkey(virtd_t) > When does virtd_t need this? Maybe a boolean with a default of off. virtd_t is a domain that deals with data from hostile sources and I think it doesn't need this in most cases so we want to limit what it can do. Thanks for doing this work. But I think it would be good if you could do some tests on some of the non-obvious cases. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/