| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <26253.1452559026@warthog.procyon.org.uk> Date: Tue, 12 Jan 2016 00:37:06 +0000 From: David Howells <dhowells@...hat.com> To: Mimi Zohar <zohar@...ux.vnet.ibm.com> Cc: dhowells@...hat.com, linux-security-module@...r.kernel.org, keyrings@...r.kernel.org, petkan@...-labs.com, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote: Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote: > > The kernel may add implicitly trusted keys to a trusted-only keyring by > > asserting KEY_ALLOC_BYPASS_RESTRICTION when the key is created, but > > otherwise the key will only be allowed to be added to the keyring if it can > > be verified. The system trusted keyring is not then special in this sense > > and other trusted keyrings can be set up that are wholly independent of > > it. > > In order to have a certificate chain of trust on any of these trusted > keyrings, the system keyring needs to be special. Even if we permit > transitive trust, meaning keys on a keyring can be used to validate > other keys being added to the same keyring, the first key added to a > trusted keyring needs to be vetted against something. That something > needs to be the builtin keys on the system keyring. Note that the KEY_ALLOC_BYPASS_RESTRICTION flag is there to permit built in keys to be added by the kernel in the first place. It would not be available to userspace to use. David
Powered by blists - more mailing lists