From: guido@trentalancia.com (Guido Trentalancia) Date: Mon, 06 Nov 2017 18:43:59 +0100 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: <40837600.Fp8dYYV2Cb@xev> References: <1509848952.10522.10.camel@trentalancia.com> <1509908457.25895.0.camel@trentalancia.com> <1509921146.10385.3.camel@trentalancia.com> <40837600.Fp8dYYV2Cb@xev> Message-ID: <1509990239.12835.23.camel@trentalancia.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Hello Russell. On Mon, 06/11/2017 at 15.53 +1100, Russell Coker wrote: > > 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. The Private Key Infrastructure /etc/pki/ directory is used for CA certificates and shared SSL private keys ("private" subdirectories). Therefore it is not a private directory for SSL private keys used by some application exclusively. If you need to further protect some specific SSL private key so that it is used only by some specific server, DO NOT SHARE it in /etc/pki/, but instead place the file in a private /etc/ subdirectory (such as /etc/apache/) and *customize* your SELinux policy so that: - a private file type is defined in such module's policy (such as "apache_ssl_privkey_t", for example); - appropriate read/manage policy interfaces are defined in the specific module's policy to operate on the new above mentioned file type (such as "apache_read_ssl_privkey()", for example). This patchset is not meant to create such customization. It is meant to properly handle operations on the *shared* SSL private key files. Also, consider that I do not have enough time available to test each single server, so the current approach is rather conservative, yet it brings a lot of protection to systems using the Reference Policy or derivates and it is therefore recommended. > > 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? To read the cacerts file. Also, consider it is not a particularly sensitive file: most servers use public versions of such file. > > 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. There is plenty of resources on the web explaining this. See, for example, a short answer: https://security.stackexchange.com/questions/139339 > > 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. See above. > > 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? There are several good resources on the web about using Samba with SSL. See, for example: https://www.oreilly.com/openbook/samba/book/appa.pdf See above for the rest of your question... > > 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. See above. It is a *shared* SSL private keys directory. > > 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. See above. > 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. You're welcome. As alredy explained, I do not have enough time available to test all possible scenarios and servers. The Reference Policy git development tree is a good start for testing. I hope this helps. Regards, Guido