* [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING @ 2023-09-07 16:52 Michal Suchanek 2023-09-07 17:32 ` Michal Suchánek 2023-09-11 21:45 ` Jarkko Sakkinen 0 siblings, 2 replies; 13+ messages in thread From: Michal Suchanek @ 2023-09-07 16:52 UTC (permalink / raw) To: linux-integrity Cc: Michal Suchanek, Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli No other platform needs CA_MACHINE_KEYRING, either. This is policy that should be decided by the administrator, not Kconfig dependencies. cc: joeyli <jlee@suse.com> Signed-off-by: Michal Suchanek <msuchanek@suse.de> --- security/integrity/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig index 232191ee09e3..b6e074ac0227 100644 --- a/security/integrity/Kconfig +++ b/security/integrity/Kconfig @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING depends on INTEGRITY_ASYMMETRIC_KEYS depends on SYSTEM_BLACKLIST_KEYRING depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS help If set, provide a keyring to which Machine Owner Keys (MOK) may be added. This keyring shall contain just MOK keys. Unlike keys -- 2.41.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-07 16:52 [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING Michal Suchanek @ 2023-09-07 17:32 ` Michal Suchánek 2023-09-12 3:39 ` Nayna 2023-09-11 21:45 ` Jarkko Sakkinen 1 sibling, 1 reply; 13+ messages in thread From: Michal Suchánek @ 2023-09-07 17:32 UTC (permalink / raw) To: linux-integrity Cc: Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, Jarkko Sakkinen, linuxppc-dev 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. > > cc: joeyli <jlee@suse.com> > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > --- > security/integrity/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > index 232191ee09e3..b6e074ac0227 100644 > --- a/security/integrity/Kconfig > +++ b/security/integrity/Kconfig > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > depends on INTEGRITY_ASYMMETRIC_KEYS > depends on SYSTEM_BLACKLIST_KEYRING > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > help > If set, provide a keyring to which Machine Owner Keys (MOK) may > be added. This keyring shall contain just MOK keys. Unlike keys > -- > 2.41.0 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-07 17:32 ` Michal Suchánek @ 2023-09-12 3:39 ` Nayna 2023-09-12 7:41 ` Michal Suchánek 2023-09-12 17:03 ` Jarkko Sakkinen 0 siblings, 2 replies; 13+ messages in thread From: Nayna @ 2023-09-12 3:39 UTC (permalink / raw) To: Michal Suchánek, linux-integrity Cc: Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, Jarkko Sakkinen, linuxppc-dev 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. INTEGRITY_CA_MACHINE_KEYRING_MAX ensures that CA is only allowed to do key signing and not code signing. Having CA signed certs also permits easy revocation of all leaf certs. Loading certificates is completely new for Power Systems. We would like to make it as clean as possible from the start. We want to enforce CA signed leaf certificates(INTEGRITY_CA_MACHINE_KEYRING). As per keyUsage(INTEGRITY_CA_MACHINE_KEYRING_MAX), if we want more flexibility, probably a boot time override can be considered. Thanks & Regards, - Nayna >> >> cc: joeyli <jlee@suse.com> >> Signed-off-by: Michal Suchanek <msuchanek@suse.de> >> --- >> security/integrity/Kconfig | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig >> index 232191ee09e3..b6e074ac0227 100644 >> --- a/security/integrity/Kconfig >> +++ b/security/integrity/Kconfig >> @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING >> depends on INTEGRITY_ASYMMETRIC_KEYS >> depends on SYSTEM_BLACKLIST_KEYRING >> depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS >> - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS >> - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS >> help >> If set, provide a keyring to which Machine Owner Keys (MOK) may >> be added. This keyring shall contain just MOK keys. Unlike keys >> -- >> 2.41.0 >> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 3:39 ` Nayna @ 2023-09-12 7:41 ` Michal Suchánek 2023-09-12 9:49 ` Jarkko Sakkinen 2023-09-12 17:03 ` Jarkko Sakkinen 1 sibling, 1 reply; 13+ messages in thread From: Michal Suchánek @ 2023-09-12 7:41 UTC (permalink / raw) To: Nayna Cc: linux-integrity, Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, Jarkko Sakkinen, linuxppc-dev 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. > INTEGRITY_CA_MACHINE_KEYRING_MAX ensures that CA is only allowed to do key > signing and not code signing. > > Having CA signed certs also permits easy revocation of all leaf certs. Revocation can be also done be removing the certificate from the keyring. If the user can add it they should also be able to remove it. > Loading certificates is completely new for Power Systems. We would like to > make it as clean as possible from the start. We want to enforce CA signed > leaf certificates(INTEGRITY_CA_MACHINE_KEYRING). As per > keyUsage(INTEGRITY_CA_MACHINE_KEYRING_MAX), if we want more flexibility, > probably a boot time override can be considered. If boot time override can exist it can as well be made permanent with a Kconfig option. I think that a boot time override is even more problematic for security than a Kconfig option - the kernel arguments are rarely signed. Thanks Michal > > Thanks & Regards, > > - Nayna > > > > > > > > cc: joeyli <jlee@suse.com> > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > > > --- > > > security/integrity/Kconfig | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > > > index 232191ee09e3..b6e074ac0227 100644 > > > --- a/security/integrity/Kconfig > > > +++ b/security/integrity/Kconfig > > > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > > > depends on INTEGRITY_ASYMMETRIC_KEYS > > > depends on SYSTEM_BLACKLIST_KEYRING > > > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > > > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > > > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > > > help > > > If set, provide a keyring to which Machine Owner Keys (MOK) may > > > be added. This keyring shall contain just MOK keys. Unlike keys > > > -- > > > 2.41.0 > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 7:41 ` Michal Suchánek @ 2023-09-12 9:49 ` Jarkko Sakkinen 2023-09-12 19:22 ` Mimi Zohar 0 siblings, 1 reply; 13+ messages in thread From: Jarkko Sakkinen @ 2023-09-12 9:49 UTC (permalink / raw) To: Michal Suchánek, Nayna Cc: linux-integrity, Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, linuxppc-dev 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. BR, Jarkko ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 9:49 ` Jarkko Sakkinen @ 2023-09-12 19:22 ` Mimi Zohar 2023-09-12 19:32 ` Jarkko Sakkinen 0 siblings, 1 reply; 13+ messages in thread From: Mimi Zohar @ 2023-09-12 19:22 UTC (permalink / raw) To: Jarkko Sakkinen, Michal Suchánek, Nayna Cc: linux-integrity, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, linuxppc-dev 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. -- thanks, Mimi ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 19:22 ` Mimi Zohar @ 2023-09-12 19:32 ` Jarkko Sakkinen 2023-09-12 19:56 ` Mimi Zohar 0 siblings, 1 reply; 13+ messages in thread From: Jarkko Sakkinen @ 2023-09-12 19:32 UTC (permalink / raw) To: Mimi Zohar, Michal Suchánek, Nayna Cc: linux-integrity, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, linuxppc-dev 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). BR, Jarkko ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 19:32 ` Jarkko Sakkinen @ 2023-09-12 19:56 ` Mimi Zohar 0 siblings, 0 replies; 13+ messages in thread From: Mimi Zohar @ 2023-09-12 19:56 UTC (permalink / raw) To: Jarkko Sakkinen, Michal Suchánek, Nayna Cc: linux-integrity, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, linuxppc-dev 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 3:39 ` Nayna 2023-09-12 7:41 ` Michal Suchánek @ 2023-09-12 17:03 ` Jarkko Sakkinen 1 sibling, 0 replies; 13+ messages in thread From: Jarkko Sakkinen @ 2023-09-12 17:03 UTC (permalink / raw) To: Nayna, Michal Suchánek, linux-integrity Cc: Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli, Eric Snowberg, Nayna Jain, linuxppc-dev On Tue Sep 12, 2023 at 6:39 AM EEST, 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. In the end this is dictating policy for no compelling reason, and that is the bottom line here, not playing a mind game what type of expertise a sysadmin might or might not have. BR, Jarkko ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-07 16:52 [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING Michal Suchanek 2023-09-07 17:32 ` Michal Suchánek @ 2023-09-11 21:45 ` Jarkko Sakkinen 2023-09-12 7:51 ` Michal Suchánek 1 sibling, 1 reply; 13+ messages in thread From: Jarkko Sakkinen @ 2023-09-11 21:45 UTC (permalink / raw) To: Michal Suchanek, linux-integrity Cc: Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli On Thu Sep 7, 2023 at 7:52 PM EEST, Michal Suchanek wrote: > No other platform needs CA_MACHINE_KEYRING, either. > > This is policy that should be decided by the administrator, not Kconfig s/administrator/distributor/ ? > dependencies. > > cc: joeyli <jlee@suse.com> > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > --- > security/integrity/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > index 232191ee09e3..b6e074ac0227 100644 > --- a/security/integrity/Kconfig > +++ b/security/integrity/Kconfig > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > depends on INTEGRITY_ASYMMETRIC_KEYS > depends on SYSTEM_BLACKLIST_KEYRING > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > help > If set, provide a keyring to which Machine Owner Keys (MOK) may > be added. This keyring shall contain just MOK keys. Unlike keys > -- > 2.41.0 I'd suggest to add even fixes tag. BR, Jarkko ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-11 21:45 ` Jarkko Sakkinen @ 2023-09-12 7:51 ` Michal Suchánek 2023-09-12 9:46 ` Jarkko Sakkinen 0 siblings, 1 reply; 13+ messages in thread From: Michal Suchánek @ 2023-09-12 7:51 UTC (permalink / raw) To: Jarkko Sakkinen Cc: linux-integrity, Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli On Tue, Sep 12, 2023 at 12:45:35AM +0300, Jarkko Sakkinen wrote: > On Thu Sep 7, 2023 at 7:52 PM EEST, Michal Suchanek wrote: > > No other platform needs CA_MACHINE_KEYRING, either. > > > > This is policy that should be decided by the administrator, not Kconfig > > s/administrator/distributor/ ? It depends on the situation. Ideally the administrator would pick the distributor that provides a policy that is considered fitting for the purpose or roll their own. Unfortunately, they don't always have the choice. For the kerenel's part it should support wide range of policies for different use cases, and not force the hand of the administrator or distributor. > > > dependencies. > > > > cc: joeyli <jlee@suse.com> > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > > --- > > security/integrity/Kconfig | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > > index 232191ee09e3..b6e074ac0227 100644 > > --- a/security/integrity/Kconfig > > +++ b/security/integrity/Kconfig > > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > > depends on INTEGRITY_ASYMMETRIC_KEYS > > depends on SYSTEM_BLACKLIST_KEYRING > > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > > help > > If set, provide a keyring to which Machine Owner Keys (MOK) may > > be added. This keyring shall contain just MOK keys. Unlike keys > > -- > > 2.41.0 > > I'd suggest to add even fixes tag. Here it is Fixes: d7d91c4743c4 ("integrity: PowerVM machine keyring enablement") Thanks Michal ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 7:51 ` Michal Suchánek @ 2023-09-12 9:46 ` Jarkko Sakkinen 2023-09-12 10:20 ` Michal Suchánek 0 siblings, 1 reply; 13+ messages in thread From: Jarkko Sakkinen @ 2023-09-12 9:46 UTC (permalink / raw) To: Michal Suchánek Cc: linux-integrity, Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli On Tue Sep 12, 2023 at 10:51 AM EEST, Michal Suchánek wrote: > On Tue, Sep 12, 2023 at 12:45:35AM +0300, Jarkko Sakkinen wrote: > > On Thu Sep 7, 2023 at 7:52 PM EEST, Michal Suchanek wrote: > > > No other platform needs CA_MACHINE_KEYRING, either. > > > > > > This is policy that should be decided by the administrator, not Kconfig > > > > s/administrator/distributor/ ? > > It depends on the situation. Ideally the administrator would pick the > distributor that provides a policy that is considered fitting for the > purpose or roll their own. Unfortunately, they don't always have the > choice. > > For the kerenel's part it should support wide range of policies for > different use cases, and not force the hand of the administrator or > distributor. > > > > > > dependencies. > > > > > > cc: joeyli <jlee@suse.com> > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > > > --- > > > security/integrity/Kconfig | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > > > index 232191ee09e3..b6e074ac0227 100644 > > > --- a/security/integrity/Kconfig > > > +++ b/security/integrity/Kconfig > > > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > > > depends on INTEGRITY_ASYMMETRIC_KEYS > > > depends on SYSTEM_BLACKLIST_KEYRING > > > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > > > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > > > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > > > help > > > If set, provide a keyring to which Machine Owner Keys (MOK) may > > > be added. This keyring shall contain just MOK keys. Unlike keys > > > -- > > > 2.41.0 > > > > I'd suggest to add even fixes tag. > > Here it is > > Fixes: d7d91c4743c4 ("integrity: PowerVM machine keyring enablement") commit b755dd58d180b796d21bc14d03045e4ab84222b0 (HEAD -> next, origin/next) Author: Michal Suchanek <msuchanek@suse.de> Date: Thu Sep 7 18:52:19 2023 +0200 integrity: powerpc: Do not select CA_MACHINE_KEYRING No other platform needs CA_MACHINE_KEYRING, either. This is policy that should be decided by the administrator, not Kconfig dependencies. Fixes: d7d91c4743c4 ("integrity: PowerVM machine keyring enablement") Signed-off-by: Michal Suchanek <msuchanek@suse.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig index 232191ee09e3..b6e074ac0227 100644 --- a/security/integrity/Kconfig +++ b/security/integrity/Kconfig @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING depends on INTEGRITY_ASYMMETRIC_KEYS depends on SYSTEM_BLACKLIST_KEYRING depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS help If set, provide a keyring to which Machine Owner Keys (MOK) may be added. This keyring shall contain just MOK keys. Unlike keys If this look good to you, I'll put it to the -rc2 pull request. > Thanks > > Michal BR, Jarkko ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING 2023-09-12 9:46 ` Jarkko Sakkinen @ 2023-09-12 10:20 ` Michal Suchánek 0 siblings, 0 replies; 13+ messages in thread From: Michal Suchánek @ 2023-09-12 10:20 UTC (permalink / raw) To: Jarkko Sakkinen Cc: linux-integrity, Mimi Zohar, Dmitry Kasatkin, Paul Moore, James Morris, Serge E. Hallyn, linux-security-module, linux-kernel, joeyli On Tue, Sep 12, 2023 at 12:46:32PM +0300, Jarkko Sakkinen wrote: > On Tue Sep 12, 2023 at 10:51 AM EEST, Michal Suchánek wrote: > > On Tue, Sep 12, 2023 at 12:45:35AM +0300, Jarkko Sakkinen wrote: > > > On Thu Sep 7, 2023 at 7:52 PM EEST, Michal Suchanek wrote: > > > > No other platform needs CA_MACHINE_KEYRING, either. > > > > > > > > This is policy that should be decided by the administrator, not Kconfig > > > > > > s/administrator/distributor/ ? > > > > It depends on the situation. Ideally the administrator would pick the > > distributor that provides a policy that is considered fitting for the > > purpose or roll their own. Unfortunately, they don't always have the > > choice. > > > > For the kerenel's part it should support wide range of policies for > > different use cases, and not force the hand of the administrator or > > distributor. > > > > > > > > > dependencies. > > > > > > > > cc: joeyli <jlee@suse.com> > > > > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > > > > --- > > > > security/integrity/Kconfig | 2 -- > > > > 1 file changed, 2 deletions(-) > > > > > > > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > > > > index 232191ee09e3..b6e074ac0227 100644 > > > > --- a/security/integrity/Kconfig > > > > +++ b/security/integrity/Kconfig > > > > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > > > > depends on INTEGRITY_ASYMMETRIC_KEYS > > > > depends on SYSTEM_BLACKLIST_KEYRING > > > > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > > > > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > > > > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > > > > help > > > > If set, provide a keyring to which Machine Owner Keys (MOK) may > > > > be added. This keyring shall contain just MOK keys. Unlike keys > > > > -- > > > > 2.41.0 > > > > > > I'd suggest to add even fixes tag. > > > > Here it is > > > > Fixes: d7d91c4743c4 ("integrity: PowerVM machine keyring enablement") > > commit b755dd58d180b796d21bc14d03045e4ab84222b0 (HEAD -> next, origin/next) > Author: Michal Suchanek <msuchanek@suse.de> > Date: Thu Sep 7 18:52:19 2023 +0200 > > integrity: powerpc: Do not select CA_MACHINE_KEYRING > > No other platform needs CA_MACHINE_KEYRING, either. > > This is policy that should be decided by the administrator, not Kconfig > dependencies. > > Fixes: d7d91c4743c4 ("integrity: PowerVM machine keyring enablement") > Signed-off-by: Michal Suchanek <msuchanek@suse.de> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> > > diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig > index 232191ee09e3..b6e074ac0227 100644 > --- a/security/integrity/Kconfig > +++ b/security/integrity/Kconfig > @@ -68,8 +68,6 @@ config INTEGRITY_MACHINE_KEYRING > depends on INTEGRITY_ASYMMETRIC_KEYS > depends on SYSTEM_BLACKLIST_KEYRING > depends on LOAD_UEFI_KEYS || LOAD_PPC_KEYS > - select INTEGRITY_CA_MACHINE_KEYRING if LOAD_PPC_KEYS > - select INTEGRITY_CA_MACHINE_KEYRING_MAX if LOAD_PPC_KEYS > help > If set, provide a keyring to which Machine Owner Keys (MOK) may > be added. This keyring shall contain just MOK keys. Unlike keys > > If this look good to you, I'll put it to the -rc2 pull request. Looks good Thanks Michal ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-09-12 19:57 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-09-07 16:52 [PATCH] integrity: powerpc: Do not select CA_MACHINE_KEYRING Michal Suchanek 2023-09-07 17:32 ` Michal Suchánek 2023-09-12 3:39 ` Nayna 2023-09-12 7:41 ` Michal Suchánek 2023-09-12 9:49 ` Jarkko Sakkinen 2023-09-12 19:22 ` Mimi Zohar 2023-09-12 19:32 ` Jarkko Sakkinen 2023-09-12 19:56 ` Mimi Zohar 2023-09-12 17:03 ` Jarkko Sakkinen 2023-09-11 21:45 ` Jarkko Sakkinen 2023-09-12 7:51 ` Michal Suchánek 2023-09-12 9:46 ` Jarkko Sakkinen 2023-09-12 10:20 ` Michal Suchánek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).