On Tue, 2023-09-12 at 22:32 +0300, Jarkko Sakkinen wrote: > On Tue Sep 12, 2023 at 10:22 PM EEST, Mimi Zohar wrote: > > On Tue, 2023-09-12 at 12:49 +0300, Jarkko Sakkinen wrote: > > > On Tue Sep 12, 2023 at 10:41 AM EEST, Michal Suchánek wrote: > > > > On Mon, Sep 11, 2023 at 11:39:38PM -0400, Nayna wrote: > > > > > > > > > > On 9/7/23 13:32, Michal Suchánek wrote: > > > > > > Adding more CC's from the original patch, looks like > > > > > > get_maintainers is > > > > > > not that great for this file. > > > > > > > > > > > > On Thu, Sep 07, 2023 at 06:52:19PM +0200, Michal Suchanek wrote: > > > > > > > No other platform needs CA_MACHINE_KEYRING, either. > > > > > > > > > > > > > > This is policy that should be decided by the administrator, not > > > > > > > Kconfig > > > > > > > dependencies. > > > > > > > > > > We certainly agree that flexibility is important. However, in this > > > > > case, > > > > > this also implies that we are expecting system admins to be security > > > > > experts. As per our understanding, CA based infrastructure(PKI) is the > > > > > standard to be followed and not the policy decision. And we can only > > > > > speak > > > > > for Power. > > > > > > > > > > INTEGRITY_CA_MACHINE_KEYRING ensures that we always have CA signed > > > > > leaf > > > > > certs. > > > > > > > > And that's the problem. > > > > > > > > From a distribution point of view there are two types of leaf certs: > > > > > > > > - leaf certs signed by the distribution CA which need not be imported > > > > because the distribution CA cert is enrolled one way or another > > > > - user generated ad-hoc certificates that are not signed in any way, > > > > and enrolled by the user > > > > > > > > The latter are vouched for by the user by enrolling the certificate, and > > > > confirming that they really want to trust this certificate. Enrolling > > > > user certificates is vital for usability or secure boot. Adding extra > > > > step of creating a CA certificate stored on the same system only > > > > complicates things with no added benefit. > > > > > > This all comes down to the generic fact that kernel should not > > > proactively define what it *expects* sysadmins. > > > > > > CA based infrastructure like anything is a policy decision not > > > a decision to be enforced by kernel. > > > > Secure boot requires a signature chain of trust. IMA extends the > > secure and trusted boot concepts to the kernel. Missing from that > > signature chain of trust is the ability of allowing the end > > machine/system owner to load other certificates without recompiling the > > kernel. The introduction of the machine keyring was to address this. > > > > I'm not questioning the end user's intent on loading local or third > > party keys via the normal mechanisms. If the existing mechanism(s) for > > loading local or third party keys were full-proof, then loading a > > single certificate, self-signed or not, would be fine. However, that > > isn't the reality. The security of the two-stage approach is simply > > not equivalent to loading a single certificate. Documentation could > > help the end user/system owner to safely create (and manage) separate > > certificate signing and code signing certs. > > > > Unlike UEFI based systems, PowerVM defines two variables trustedcadb > > and moduledb, for storing certificate signing and code signing > > certificates respectively. First the certs on the trustedcadb are > > loaded and then the ones on moduledb are loaded. > > There's pragmatic reasons to make things more open than they should be > in production. As a hardware example I still possess Raspberry Pi 3B for > test workloads because it has a broken TZ implementation. The world is > really bigger than production workloads. > > It would be better to document what you said rather than enforce the > right choice IMHO (e.g. extend Kconfig documentation).
PowerVM LPARs are more about production workloads than a Raspberry Pi. :) -- thanks, Mimi
