From: jason@perfinion.com (Jason Zaman)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] cert_t
Date: Thu, 18 Sep 2014 02:00:47 +0800 [thread overview]
Message-ID: <20140917180047.GA11344@meriadoc> (raw)
In-Reply-To: <201409131443.09899.russell@coker.com.au>
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
next prev parent reply other threads:[~2014-09-17 18:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2014-09-18 13:28 ` Christopher J. PeBenito
2014-09-18 14:28 ` Dominick Grift
2014-09-19 18:37 ` Christopher J. PeBenito
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140917180047.GA11344@meriadoc \
--to=jason@perfinion.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.