From: Daniel Axtens <dja@axtens.net>
To: Joel Stanley <joel@jms.id.au>, linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/config: Enable secuity features in skiroot
Date: Mon, 06 Jan 2020 16:28:04 +1100 [thread overview]
Message-ID: <87k165nogr.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <20200102073058.163746-1-joel@jms.id.au>
Joel Stanley <joel@jms.id.au> writes:
> This turns on HARDENED_USERCOPY with HARDENED_USERCOPY_PAGESPAN, and
> FORTIFY_SOURCE.
>
> It also enables SECURITY_LOCKDOWN_LSM with _EARLY and
> LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY options enabled.
This will completely disable xmon when combined with 69393cb03ccd
("powerpc/xmon: Restrict when kernel is locked down"). I don't
personally have a problem with this, but I think not disabling xmon has
come up before as a requirement of some developers.
Is forcing integrity not sufficient? What confidential data held by the
skiroot kernel are you trying to protect? If you just force integrity
you'll get xmon in read-only mode, which should be fine for most
debugging...
Regards,
Daniel
>
> MODULE_SIG is selected by lockdown, so it is still enabled.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/powerpc/configs/skiroot_defconfig | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/configs/skiroot_defconfig b/arch/powerpc/configs/skiroot_defconfig
> index 069f67f12731..0a441c414a57 100644
> --- a/arch/powerpc/configs/skiroot_defconfig
> +++ b/arch/powerpc/configs/skiroot_defconfig
> @@ -33,7 +33,6 @@ CONFIG_JUMP_LABEL=y
> CONFIG_STRICT_KERNEL_RWX=y
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> -CONFIG_MODULE_SIG=y
> CONFIG_MODULE_SIG_FORCE=y
> CONFIG_MODULE_SIG_SHA512=y
> CONFIG_PARTITION_ADVANCED=y
> @@ -297,5 +296,15 @@ CONFIG_WQ_WATCHDOG=y
> CONFIG_XMON=y
> CONFIG_XMON_DEFAULT=y
> CONFIG_ENCRYPTED_KEYS=y
> +CONFIG_SECURITY=y
> +CONFIG_HARDENED_USERCOPY=y
> +# CONFIG_HARDENED_USERCOPY_FALLBACK is not set
> +CONFIG_HARDENED_USERCOPY_PAGESPAN=y
> +CONFIG_FORTIFY_SOURCE=y
> +CONFIG_SECURITY_LOCKDOWN_LSM=y
> +CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
> +CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y
> +# CONFIG_INTEGRITY is not set
> +CONFIG_LSM="yama,loadpin,safesetid,integrity"
> # CONFIG_CRYPTO_ECHAINIV is not set
> # CONFIG_CRYPTO_HW is not set
> --
> 2.24.1
prev parent reply other threads:[~2020-01-06 5:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-02 7:30 Joel Stanley
2020-01-06 5:28 ` Daniel Axtens [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k165nogr.fsf@dja-thinkpad.axtens.net \
--to=dja@axtens.net \
--cc=joel@jms.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®