[PATCH] docs: Add Security Hardening Suggestions

[PATCH] docs: Add Security Hardening Suggestions

[Andrew Hamilton]

Add some suggestions to the security section on maximizing the
security hardening of GRUB.

Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
---
 docs/grub.texi | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/docs/grub.texi b/docs/grub.texi
index 34b3484dc..55170e589 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -8675,6 +8675,7 @@ environment variables and commands are listed in the same order.
 * Measured Boot::                    Measuring boot components
 * Lockdown::                         Lockdown when booting on a secure setup
 * TPM2 key protector::               Managing disk key with TPM2 key protector
+* Hardening::                        Configuration and customization to maximize security
 @end menu
 
 @node Authentication and authorisation
@@ -9363,6 +9364,50 @@ which increases the risk of password leakage during the process. Moreover, the
 superuser list must be well maintained, and the password used cannot be
 synchronized with LUKS key rotation.
 
+@node Hardening
+@section Hardening
+
+Security hardening involves additional / optional configuration and
+customization steps to GRUB to maximize security. The extent to which
+hardening can be accomplished depends on the threats attempting to be
+mitigated for a given system / device, the device architecture, and number
+of GRUB features required. The following is a listing of hardening steps which
+may be considered:
+
+@itemize
+@item (EFI Only) Enable secure boot to enable lockdown mode. This will limit
+the attack surface of GRUB by limiting the commands and file systems
+supported. (@pxref{Lockdown})
+@item (EFI Only) No-Execute capability of memory segments will be configured
+by GRUB as indicated by the UEFI. This makes some classes of vulnerabilities
+more difficult by providing support for marking memory as either writable or
+executable.
+@item (EFI Only) While building GRUB, the stack protector feature may be
+enabled during the configuration step. This feature can make certain
+vulnerabilities caused by stack buffer overflows more difficult to exploit.
+This can be enabled by including the "--enable-stack-protector" flag to the
+configure script:
+@example
+# @kbd{./configure --enable-stack-protector}
+@end example
+Please reference the file @file{INSTALL} for detailed instructions on how to
+build GRUB.
+@item Minimize the installed modules included with the GRUB installation.
+For instance, if a specific file system is used for a given system, modules
+for other file systems may be excluded. @pxref{Modules} for a list of
+modules.
+@item Minimize boot sources. In the GRUB configuration, reduce the possible
+boot sources to the minimum needed for system operation. For instance, if
+booting only from an internal drive, remove support for network booting
+and booting from removable media.
+@item Disable network support in GRUB if not required. Ensure network
+interfaces are not configured in the GRUB configuration and consider
+setting environment variable @samp{feature_net_search_cfg} to @samp{n} in an
+embedded GRUB config file in order to disable attempting to use the
+network for obtaining a GRUB config file.
+@end itemize
+
+
 @node Platform limitations
 @chapter Platform limitations
 
-- 
2.47.2


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] docs: Add Security Hardening Suggestions

[Daniel Kiper]

On Sun, Sep 07, 2025 at 08:40:41AM -0500, Andrew Hamilton wrote:
> Add some suggestions to the security section on maximizing the
> security hardening of GRUB.
>
> Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
> ---
>  docs/grub.texi | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 34b3484dc..55170e589 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -8675,6 +8675,7 @@ environment variables and commands are listed in the same order.
>  * Measured Boot::                    Measuring boot components
>  * Lockdown::                         Lockdown when booting on a secure setup
>  * TPM2 key protector::               Managing disk key with TPM2 key protector
> +* Hardening::                        Configuration and customization to maximize security
>  @end menu
>
>  @node Authentication and authorisation
> @@ -9363,6 +9364,50 @@ which increases the risk of password leakage during the process. Moreover, the
>  superuser list must be well maintained, and the password used cannot be
>  synchronized with LUKS key rotation.
>
> +@node Hardening
> +@section Hardening
> +
> +Security hardening involves additional / optional configuration and
> +customization steps to GRUB to maximize security. The extent to which
> +hardening can be accomplished depends on the threats attempting to be
> +mitigated for a given system / device, the device architecture, and number
> +of GRUB features required. The following is a listing of hardening steps which
> +may be considered:
> +
> +@itemize
> +@item (EFI Only) Enable secure boot to enable lockdown mode. This will limit
> +the attack surface of GRUB by limiting the commands and file systems
> +supported. (@pxref{Lockdown})
> +@item (EFI Only) No-Execute capability of memory segments will be configured
> +by GRUB as indicated by the UEFI. This makes some classes of vulnerabilities
> +more difficult by providing support for marking memory as either writable or

s/difficult/difficult to exploit/

I will fix this for you.

Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] docs: Add Security Hardening Suggestions

[Daniel Kiper]

On Thu, Nov 06, 2025 at 02:21:19PM +0100, Daniel Kiper wrote:
> On Sun, Sep 07, 2025 at 08:40:41AM -0500, Andrew Hamilton wrote:
> > Add some suggestions to the security section on maximizing the
> > security hardening of GRUB.
> >
> > Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
> > ---
> >  docs/grub.texi | 45 +++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 45 insertions(+)
> >
> > diff --git a/docs/grub.texi b/docs/grub.texi
> > index 34b3484dc..55170e589 100644
> > --- a/docs/grub.texi
> > +++ b/docs/grub.texi
> > @@ -8675,6 +8675,7 @@ environment variables and commands are listed in the same order.
> >  * Measured Boot::                    Measuring boot components
> >  * Lockdown::                         Lockdown when booting on a secure setup
> >  * TPM2 key protector::               Managing disk key with TPM2 key protector
> > +* Hardening::                        Configuration and customization to maximize security
> >  @end menu
> >
> >  @node Authentication and authorisation
> > @@ -9363,6 +9364,50 @@ which increases the risk of password leakage during the process. Moreover, the
> >  superuser list must be well maintained, and the password used cannot be
> >  synchronized with LUKS key rotation.
> >
> > +@node Hardening
> > +@section Hardening
> > +
> > +Security hardening involves additional / optional configuration and
> > +customization steps to GRUB to maximize security. The extent to which
> > +hardening can be accomplished depends on the threats attempting to be
> > +mitigated for a given system / device, the device architecture, and number
> > +of GRUB features required. The following is a listing of hardening steps which
> > +may be considered:
> > +
> > +@itemize
> > +@item (EFI Only) Enable secure boot to enable lockdown mode. This will limit
> > +the attack surface of GRUB by limiting the commands and file systems
> > +supported. (@pxref{Lockdown})
> > +@item (EFI Only) No-Execute capability of memory segments will be configured
> > +by GRUB as indicated by the UEFI. This makes some classes of vulnerabilities
> > +more difficult by providing support for marking memory as either writable or
>
> s/difficult/difficult to exploit/
>
> I will fix this for you.
>
> Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Well, the patch does not apply on latest master. May I ask you to rebase
the patch on top of it?

Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] docs: Add Security Hardening Suggestions

[Andrew Hamilton]

[-- Attachment #1.1: Type: text/plain, Size: 2700 bytes --]

Yes, will do!

On Thu, Nov 6, 2025 at 2:29 PM Daniel Kiper <dkiper@net-space.pl> wrote:

> On Thu, Nov 06, 2025 at 02:21:19PM +0100, Daniel Kiper wrote:
> > On Sun, Sep 07, 2025 at 08:40:41AM -0500, Andrew Hamilton wrote:
> > > Add some suggestions to the security section on maximizing the
> > > security hardening of GRUB.
> > >
> > > Signed-off-by: Andrew Hamilton <adhamilt@gmail.com>
> > > ---
> > >  docs/grub.texi | 45 +++++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 45 insertions(+)
> > >
> > > diff --git a/docs/grub.texi b/docs/grub.texi
> > > index 34b3484dc..55170e589 100644
> > > --- a/docs/grub.texi
> > > +++ b/docs/grub.texi
> > > @@ -8675,6 +8675,7 @@ environment variables and commands are listed in
> the same order.
> > >  * Measured Boot::                    Measuring boot components
> > >  * Lockdown::                         Lockdown when booting on a
> secure setup
> > >  * TPM2 key protector::               Managing disk key with TPM2 key
> protector
> > > +* Hardening::                        Configuration and customization
> to maximize security
> > >  @end menu
> > >
> > >  @node Authentication and authorisation
> > > @@ -9363,6 +9364,50 @@ which increases the risk of password leakage
> during the process. Moreover, the
> > >  superuser list must be well maintained, and the password used cannot
> be
> > >  synchronized with LUKS key rotation.
> > >
> > > +@node Hardening
> > > +@section Hardening
> > > +
> > > +Security hardening involves additional / optional configuration and
> > > +customization steps to GRUB to maximize security. The extent to which
> > > +hardening can be accomplished depends on the threats attempting to be
> > > +mitigated for a given system / device, the device architecture, and
> number
> > > +of GRUB features required. The following is a listing of hardening
> steps which
> > > +may be considered:
> > > +
> > > +@itemize
> > > +@item (EFI Only) Enable secure boot to enable lockdown mode. This
> will limit
> > > +the attack surface of GRUB by limiting the commands and file systems
> > > +supported. (@pxref{Lockdown})
> > > +@item (EFI Only) No-Execute capability of memory segments will be
> configured
> > > +by GRUB as indicated by the UEFI. This makes some classes of
> vulnerabilities
> > > +more difficult by providing support for marking memory as either
> writable or
> >
> > s/difficult/difficult to exploit/
> >
> > I will fix this for you.
> >
> > Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
>
> Well, the patch does not apply on latest master. May I ask you to rebase
> the patch on top of it?
>
> Daniel
>

[-- Attachment #1.2: Type: text/html, Size: 3509 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel