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/
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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | oss.tresys.com