linux-kernel - Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025061938-making-igloo-3326@gregkh>
Date: Thu, 19 Jun 2025 13:20:58 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Marwan Seliem <marwanmhks@...il.com>
Cc: jirislaby@...nel.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode

On Wed, Jun 11, 2025 at 09:33:49AM +0300, Marwan Seliem wrote:
> Hi Jiri,
> 
> Thank you for your review and feedback. Let me address your comments and provide more context about the use case for this change.
> 
> > I must admit I don't much understand the purpose of this. It can be
> > spelled as: you can crash the system only by sysrq-c from now on. Don't
> > use sysrq-r or others. Who did ask for this?
> 
> This change was created with embedded systems that have external subsystems in mind (like modems/co-processors) where we need:
>     - The ability to trigger a full system crash (via sysrq-c) to collect subsystem crash dumps
>     - While explicitly disabling all other sysrq functionality for security reasons

"security" involves crashing the system, so I fail to understand why one
is more "secure" than the other.

Sorry, someone needs to go back and talk to the people who think that
this is going to result in a more secure system as that's just not the
case at all.

> In these environments:
>     - Crash dumps are essential for debugging
> 	- Other sysrq commands pose unnecessary security risks

Again, I don't buy it, sorry.

> > Is it for real?
> 
> >From a pure security viewpoint, expert advice is to remove this Magic Sysrq functionality, 
> either with kernel.sysrq=0 in sysctl config file, or with a full kernel rebuild 
> with n value for CONFIG_MAGIC_SYSRQ parameter.
> This patch provides a middle ground that:
>     1) Resolves the Core Security Conflict
> 		The CRASH_ONLY mode provides the minimal debug capability while eliminating:
>             - Register dumps (disables 'p' command)
>             - Filesystem operations (disables 'u'/sync commands)
>             - All other privileged operations
>     2) Security Architecture Benefits
> 	
> 		Traditional: All-or-nothing  
> 		│─────────────┬─────────────│  
> 			Full disable			Full enable  
> 
> 		Our Approach: Principle of Least Privilege  
> 		│─────┬───────┬─────────────│  
> 			Off	Crash-only		Full enable  

I don't understand your graphs here, what are you trying to say?
Somehow still allowing someone to crash the system still is "secure"?

confused,

greg k-h