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
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ