Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #58071 > unrolled thread
| Started by | Matthew Garrett <mjg59@google.com> |
|---|---|
| First post | 2017-06-20 11:00 +0200 |
| Last post | 2017-07-17 02:40 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.debian.kernel
Bug#865277: Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING Matthew Garrett <mjg59@google.com> - 2017-06-20 11:00 +0200
Bug#865277: marked as done (Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING) owner@bugs.debian.org (Debian Bug Tracking System) - 2017-07-17 02:40 +0200
| From | Matthew Garrett <mjg59@google.com> |
|---|---|
| Date | 2017-06-20 11:00 +0200 |
| Subject | Bug#865277: Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING |
| Message-ID | <tUnaW-6kQ-13@gated-at.bofh.it> |
Package: linux
Severity: wishlist
CONFIG_INTEGRITY_TRUSTED_KEYRING is documented as:
This option requires that all keys added to the .ima and
.evm keyrings be signed by a key on the system trusted
keyring.
This means that it's impossible to add keys to the .ima or .evm
keyrings unless those keys are signed by a key in the trusted keyring.
The trusted keyring is defined at compile time as containing only
debian/certs/benh@debian.org.cert.pem, so ima and evm keys can only be
added if they're signed by Debian.
This isn't ideal for a general purpose binary distribution, and
doesn't make a great deal of sense anyway. IMA will do nothing by
default unless a policy is configured at boot time, which means that
it requires a trusted boot chain that will load the initial IMA
policy. It's reasonable to assert that anything trusted to load policy
should also be trusted to load the initial trusted keyset.
Userspace has two choices: they can either add raw keys to the IMA
keyring and then lock it down so new keys can't be added, or they can
create a new keyring containing the trusted certificate chain and lock
it down, and then restrict the IMA keyring with
KEYCTL_RESTRICT_KEYRING such that it will only load keys signed by
keys in the new trusted keyring. The second case is equivalent to the
behaviour where CONFIG_INTEGRITY_TRUSTED_KEYRING is enabled, except
that a trusted keyring under user control is used rather than one
under Debian's control. This allows the local admin to decide which
keys they trust, whereas right now Debian is the only organisation
able to make that decision for the user.
[toc] | [next] | [standalone]
| From | owner@bugs.debian.org (Debian Bug Tracking System) |
|---|---|
| Date | 2017-07-17 02:40 +0200 |
| Subject | Bug#865277: marked as done (Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING) |
| Message-ID | <u42eR-6dG-1@gated-at.bofh.it> |
| In reply to | #58071 |
[Multipart message — attachments visible in raw view] — view raw
Your message dated Mon, 17 Jul 2017 01:30:59 +0100 with message-id <1500251459.2707.198.camel@decadent.org.uk> and subject line Re: Bug#865277: Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING has caused the Debian Bug report #865277, regarding Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 865277: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865277 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web