From: russell@coker.com.au (Russell Coker) Date: Wed, 5 Apr 2017 14:12:06 +1000 Subject: [refpolicy] [PATCH] misc fc changes In-Reply-To: References: <20170402085805.2zlddx2evzcgxgop@athena.coker.com.au> <201704041121.03619.russell@coker.com.au> Message-ID: <201704051412.06231.russell@coker.com.au> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 5 Apr 2017 08:50:56 AM Chris PeBenito wrote: > >> I think I'm ok with everything else except this. Why shouldn't all > >> those certs be protected specially? > > > > The private directory is for private keys that need protection. > > /etc/ssh/certs is for public keys of CAs that need to be read by many > > programs that don't need access to private keys (IE any program that > > wants to verify a SSL server). /etc/ssh/openssl.cnf is for openssl > > configuration that again may be read by programs that don't have any > > particular privileges. > > In that case, /etc/ssl/private should be a different type, as all the > public certs are cert_t. What is the point of having a type for just public keys? On most systems the only public keys are those which are supplied by the distribution, they are read-only configuration files. On the minority of systems that have locally installed public keys they are just like any other configuration file locally installed by the sysadmin. Why would any type other than etc_t be desired? Now we do have a problem of many domains having access to cert_t that don't deserve access to private keys, from a casual examination it seems mostly SSL clients, along with some things that are just strange (EG useradd_t). So probably the best thing to do would be to make cert_t an alias for etc_t and create a new private_key_t for the private keys in question. In the mean-time could you please apply the rest of that patch to the git repository? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/