[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#865277: marked as done (Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING)

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
--- Begin Message --- 
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.

--- End Message ---
--- Begin Message --- 
On Tue, 2017-06-20 at 10:48 +0200, Matthew Garrett wrote:
[...]
> 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.
[...]

We never really enabled it, since we didn't enable
CONFIG_INTEGRITY_SIGNATURE which it depends on.  However, I will delete
it from the config fragment in the source package now.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
                                                    - Carolyn Scheppner

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: