* [refpolicy] cert_t @ 2014-09-13 4:43 Russell Coker 2014-09-15 19:26 ` Christopher J. PeBenito 2014-09-17 18:00 ` Jason Zaman 0 siblings, 2 replies; 6+ messages in thread From: Russell Coker @ 2014-09-13 4:43 UTC (permalink / raw) To: refpolicy What's the point of cert_t? It's used for private keys as well as config files such as openssl.cnf which don't seem particularly secret. What is the aim of it? Should it be just used for the secret files (EG /etc/ssh/private/*)? Currently the ssh client fails on Debian/Unstable because ssh_t isn't permitted to access cert_t. Audit2allow tells me that enabling the boolean authlogin_nsswitch_use_ldap would permit such access which suggests that we might have further problems with cert_t. Presumably allowing LDAP authentication shouldn't mean that network facing programs such as the ssh client get to read SSL private keys. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] cert_t 2014-09-13 4:43 [refpolicy] cert_t Russell Coker @ 2014-09-15 19:26 ` Christopher J. PeBenito 2014-09-17 18:00 ` Jason Zaman 1 sibling, 0 replies; 6+ messages in thread From: Christopher J. PeBenito @ 2014-09-15 19:26 UTC (permalink / raw) To: refpolicy On 9/13/2014 12:43 AM, Russell Coker wrote: > What's the point of cert_t? It's used for private keys as well as config > files such as openssl.cnf which don't seem particularly secret. I don't think it's as much for keeping things secret but rather to constrain who can write to it, instead of letting it be etc_t or something similar. That being said, having openssl.cnf being cert_t is probably overspecified, and we should probably keep cert_t to certificates and other key materials. > What is the aim of it? Should it be just used for the secret files (EG > /etc/ssh/private/*)? > > Currently the ssh client fails on Debian/Unstable because ssh_t isn't > permitted to access cert_t. Audit2allow tells me that enabling the boolean > authlogin_nsswitch_use_ldap would permit such access which suggests that we > might have further problems with cert_t. Presumably allowing LDAP > authentication shouldn't mean that network facing programs such as the ssh > client get to read SSL private keys. > -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] cert_t 2014-09-13 4:43 [refpolicy] cert_t Russell Coker 2014-09-15 19:26 ` Christopher J. PeBenito @ 2014-09-17 18:00 ` Jason Zaman 2014-09-18 13:28 ` Christopher J. PeBenito 1 sibling, 1 reply; 6+ messages in thread From: Jason Zaman @ 2014-09-17 18:00 UTC (permalink / raw) To: refpolicy On Sat, Sep 13, 2014 at 02:43:09PM +1000, Russell Coker wrote: > What's the point of cert_t? It's used for private keys as well as config > files such as openssl.cnf which don't seem particularly secret. > > What is the aim of it? Should it be just used for the secret files (EG > /etc/ssh/private/*)? > > Currently the ssh client fails on Debian/Unstable because ssh_t isn't > permitted to access cert_t. Audit2allow tells me that enabling the boolean > authlogin_nsswitch_use_ldap would permit such access which suggests that we > might have further problems with cert_t. Presumably allowing LDAP > authentication shouldn't mean that network facing programs such as the ssh > client get to read SSL private keys. This reminded me of something similar, I've actually been wondering about gpg_secret_t. HOME_DIR/\.gnupg(/.+)? gen_context(system_u:object_r:gpg_secret_t,s0) the dir does not seem particularly secret, gpg.conf and gpg-agent.conf etc. On the other hand, the secring.gpg is *very* secret. There are quite a lot of things on my machine that can read gpg_secret_t files. Ideally i would think there should be a gpg_home_t for the dir and then the secring is gpg_secret_t and access to gpg_secret_t should be removed. I dont see why anything other than gpg should be able to read the file. Should i send a patch to do this? or is there a reason it is how it is that i am unaware of? -- Jason > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy ^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] cert_t 2014-09-17 18:00 ` Jason Zaman @ 2014-09-18 13:28 ` Christopher J. PeBenito 2014-09-18 14:28 ` Dominick Grift 0 siblings, 1 reply; 6+ messages in thread From: Christopher J. PeBenito @ 2014-09-18 13:28 UTC (permalink / raw) To: refpolicy On 9/17/2014 2:00 PM, Jason Zaman wrote: > On Sat, Sep 13, 2014 at 02:43:09PM +1000, Russell Coker wrote: >> What's the point of cert_t? It's used for private keys as well as config >> files such as openssl.cnf which don't seem particularly secret. >> >> What is the aim of it? Should it be just used for the secret files (EG >> /etc/ssh/private/*)? >> >> Currently the ssh client fails on Debian/Unstable because ssh_t isn't >> permitted to access cert_t. Audit2allow tells me that enabling the boolean >> authlogin_nsswitch_use_ldap would permit such access which suggests that we >> might have further problems with cert_t. Presumably allowing LDAP >> authentication shouldn't mean that network facing programs such as the ssh >> client get to read SSL private keys. > > This reminded me of something similar, I've actually been wondering > about gpg_secret_t. > > HOME_DIR/\.gnupg(/.+)? gen_context(system_u:object_r:gpg_secret_t,s0) > > the dir does not seem particularly secret, gpg.conf and gpg-agent.conf > etc. On the other hand, the secring.gpg is *very* secret. There are > quite a lot of things on my machine that can read gpg_secret_t files. > > Ideally i would think there should be a gpg_home_t for the dir and then > the secring is gpg_secret_t and access to gpg_secret_t should be > removed. I dont see why anything other than gpg should be able to read > the file. Should i send a patch to do this? or is there a reason it is > how it is that i am unaware of? To clarify, you mean everything in the directory is gpg_home_t, except for the private keys, which are gpg_secret_t? If so, that sounds reasonable. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] cert_t 2014-09-18 13:28 ` Christopher J. PeBenito @ 2014-09-18 14:28 ` Dominick Grift 2014-09-19 18:37 ` Christopher J. PeBenito 0 siblings, 1 reply; 6+ messages in thread From: Dominick Grift @ 2014-09-18 14:28 UTC (permalink / raw) To: refpolicy On Thu, Sep 18, 2014 at 09:28:38AM -0400, Christopher J. PeBenito wrote: > On 9/17/2014 2:00 PM, Jason Zaman wrote: > > On Sat, Sep 13, 2014 at 02:43:09PM +1000, Russell Coker wrote: > >> What's the point of cert_t? It's used for private keys as well as config > >> files such as openssl.cnf which don't seem particularly secret. > >> > >> What is the aim of it? Should it be just used for the secret files (EG > >> /etc/ssh/private/*)? > >> > >> Currently the ssh client fails on Debian/Unstable because ssh_t isn't > >> permitted to access cert_t. Audit2allow tells me that enabling the boolean > >> authlogin_nsswitch_use_ldap would permit such access which suggests that we > >> might have further problems with cert_t. Presumably allowing LDAP > >> authentication shouldn't mean that network facing programs such as the ssh > >> client get to read SSL private keys. > > > > This reminded me of something similar, I've actually been wondering > > about gpg_secret_t. > > > > HOME_DIR/\.gnupg(/.+)? gen_context(system_u:object_r:gpg_secret_t,s0) > > > > the dir does not seem particularly secret, gpg.conf and gpg-agent.conf > > etc. On the other hand, the secring.gpg is *very* secret. There are > > quite a lot of things on my machine that can read gpg_secret_t files. > > > > Ideally i would think there should be a gpg_home_t for the dir and then > > the secring is gpg_secret_t and access to gpg_secret_t should be > > removed. I dont see why anything other than gpg should be able to read > > the file. Should i send a patch to do this? or is there a reason it is > > how it is that i am unaware of? > > To clarify, you mean everything in the directory is gpg_home_t, except > for the private keys, which are gpg_secret_t? If so, that sounds > reasonable. > I also like the idea of tightening access to the private key but i see some potential issues For one, i suspect that one can have multiple private keys in there. If true then this makes it hard to use named-based file type transitions for the private keys A hack would be to create name-based file type transitions for anything *but* the private keys instead however this is probably just as prone to error. The question also arises, to what end? We've spoken about this and it turns out, i believe, that OP wants to disallow at least read access to the user domain associated with the user owning the file. My reply to that was that the main reason for such a requirement probably is that so many programs currently run in the user domain, and that it would not so much be a problem if the user himself could read the file This leads me to believe that this implementation is more of a cure for a symptom rather than a cure for the root of the problem, namely (long running) processes running in the user domain that have access to the file. In practice very few programs need access to ~/.gnupg regular files at least. One of them is gpgagent which in refpolicy is also covered gpgagent needs to be able to read and maybe even maintain gpg-agent.conf as well as be able to maintain a gpg-agent socket in there There are a few other exceptions like gnupg scdaemon. In conclusion. In my view the fix to the problem is to target user agents instead, and disallow user agents access to regular files with type gpg_secret_t however i realize that this is probably an unachievable goal in a general purpose policy (we cant predict what programs are run by users, and we dont have the man power to target all conceivable threats in the user session)) Preventing the user domain associated with the user owning they key access to the key in any way sounds like a sub-optimal solution. All in all i see difficulties implementing this, and it appears to me as a bit of an ugly hack As someone who has been advocating for integrity in the user session i obviously agree with the assessment that currently too many processes have to much access to sensitive files like these. It's just this solution that i do not really like. But if the maintainer wants it then i will be happy to commit it either way because i know that with the territory of general purpose comes compromise, and i will be willing to compromise. I just want everyone to understand the pro's and con's of this "solution". -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://subkeys.pgp.net:11371/pks/lookup?search=0x02DFF788&op=index Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 648 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140918/d98b5856/attachment.bin ^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] cert_t 2014-09-18 14:28 ` Dominick Grift @ 2014-09-19 18:37 ` Christopher J. PeBenito 0 siblings, 0 replies; 6+ messages in thread From: Christopher J. PeBenito @ 2014-09-19 18:37 UTC (permalink / raw) To: refpolicy On 9/18/2014 10:28 AM, Dominick Grift wrote: > On Thu, Sep 18, 2014 at 09:28:38AM -0400, Christopher J. PeBenito > wrote: >> On 9/17/2014 2:00 PM, Jason Zaman wrote: >>> On Sat, Sep 13, 2014 at 02:43:09PM +1000, Russell Coker wrote: >>>> What's the point of cert_t? It's used for private keys as >>>> well as config files such as openssl.cnf which don't seem >>>> particularly secret. >>>> >>>> What is the aim of it? Should it be just used for the secret >>>> files (EG /etc/ssh/private/*)? >>>> >>>> Currently the ssh client fails on Debian/Unstable because >>>> ssh_t isn't permitted to access cert_t. Audit2allow tells me >>>> that enabling the boolean authlogin_nsswitch_use_ldap would >>>> permit such access which suggests that we might have further >>>> problems with cert_t. Presumably allowing LDAP >>>> authentication shouldn't mean that network facing programs >>>> such as the ssh client get to read SSL private keys. >>> >>> This reminded me of something similar, I've actually been >>> wondering about gpg_secret_t. >>> >>> HOME_DIR/\.gnupg(/.+)? >>> gen_context(system_u:object_r:gpg_secret_t,s0) >>> >>> the dir does not seem particularly secret, gpg.conf and >>> gpg-agent.conf etc. On the other hand, the secring.gpg is >>> *very* secret. There are quite a lot of things on my machine >>> that can read gpg_secret_t files. >>> >>> Ideally i would think there should be a gpg_home_t for the dir >>> and then the secring is gpg_secret_t and access to gpg_secret_t >>> should be removed. I dont see why anything other than gpg >>> should be able to read the file. Should i send a patch to do >>> this? or is there a reason it is how it is that i am unaware >>> of? >> >> To clarify, you mean everything in the directory is gpg_home_t, >> except for the private keys, which are gpg_secret_t? If so, that >> sounds reasonable. >> > > I also like the idea of tightening access to the private key but i > see some potential issues > > For one, i suspect that one can have multiple private keys in > there. If true then this makes it hard to use named-based file type > transitions for the private keys > > A hack would be to create name-based file type transitions for > anything *but* the private keys instead however this is probably > just as prone to error. > > The question also arises, to what end? > > We've spoken about this and it turns out, i believe, that OP wants > to disallow at least read access to the user domain associated with > the user owning the file. > > My reply to that was that the main reason for such a requirement > probably is that so many programs currently run in the user domain, > and that it would not so much be a problem if the user himself > could read the file > > This leads me to believe that this implementation is more of a cure > for a symptom rather than a cure for the root of the problem, > namely (long running) processes running in the user domain that > have access to the file. > > In practice very few programs need access to ~/.gnupg regular files > at least. One of them is gpgagent which in refpolicy is also > covered gpgagent needs to be able to read and maybe even maintain > gpg-agent.conf as well as be able to maintain a gpg-agent socket in > there > > There are a few other exceptions like gnupg scdaemon. > > In conclusion. In my view the fix to the problem is to target user > agents instead, and disallow user agents access to regular files > with type gpg_secret_t however i realize that this is probably an > unachievable goal in a general purpose policy (we cant predict what > programs are run by users, and we dont have the man power to target > all conceivable threats in the user session)) > > Preventing the user domain associated with the user owning they key > access to the key in any way sounds like a sub-optimal solution. > > All in all i see difficulties implementing this, and it appears to > me as a bit of an ugly hack > > As someone who has been advocating for integrity in the user > session i obviously agree with the assessment that currently too > many processes have to much access to sensitive files like these. > > It's just this solution that i do not really like. > > But if the maintainer wants it then i will be happy to commit it > either way because i know that with the territory of general > purpose comes compromise, and i will be willing to compromise. I'm not requiring any changes. If the proposed change doesn't work, then I'm fine making no changes. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-19 18:37 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-13 4:43 [refpolicy] cert_t Russell Coker 2014-09-15 19:26 ` Christopher J. PeBenito 2014-09-17 18:00 ` Jason Zaman 2014-09-18 13:28 ` Christopher J. PeBenito 2014-09-18 14:28 ` Dominick Grift 2014-09-19 18:37 ` Christopher J. PeBenito
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.