On Wed, Aug 15, 2018 at 09:06:13PM +0200, Yannik Sembritzki wrote: > > > I am wondering why did we have to split this keyring to begin with. > > So there are use cases where we want to trust builtin keys but > > not the ones which came from other places (UEFI secure boot db, or > > user loaded one)? > > > "User loaded ones" should not be trusted in general to prevent rootkits > and similar from modifying the kernel (even if they have root). > > According to the patch which introduced the secondary keyring (the one > you mentioned), the requirements for adding keys to the secondary > keyring are as follows: > "Add a secondary system keyring that can be added to by root whilst the > system is running - provided the key being added is vouched for by a key > built into the kernel or already added to the secondary keyring." >
Right. So it will become a question of should we trust a key which is possibly dynamically loaded into the kernel, and which has been trusted by an existing key. So this sounds like extending chain of trust to a key which is dynamically loaded later. I feels reasonable to me to extend chain of trust for kexec kernel. (Until and unless somebody has a use case in mind where this is not a good idea). I see that module signing code trusts only builtin keys and not the keys in secondary_trusted_keys keyring. Dave, what's the reason behind having two keyrings. Is it because module signing code does not want to trust keys other than built-in ones? Thanks Vivek > I personally don't see a reason for this split, as the requirements for > the secondary keyring are as strict as it can get. However, I'm new to > this, so feel free to correct me. > > Yannik >
