SysRq (Magic SysRq key)

madaidan · January 21, 2020, 7:54pm

Should CONFIG_MAGIC_SYSRQ be disabled in hardened-kernel to get rid of it entirely or should we just whitelist a few functions like SAK?

Patrick_mobile · January 21, 2020, 9:03pm

Need SAK for Safely Use Root Commands

Anything else that makes sense?

madaidan · January 22, 2020, 5:00pm

The o command can be used to quickly shutdown if in an emergency but this makes it easier for DoS and is much better done on the host.

The f command can be used to kill a process taking up too much memory which might be useful to save the system from crashing.

Patrick · January 22, 2020, 6:41pm

Not sure how fine granular we can whitelist whatever we want?

madaidan via Whonix Forum:

Patrick_mobile:

Anything else that makes sense?

The o command can be used to quickly shutdown if in an emergency but this makes it easier for DoS and is much better done on the host.

Yes but if we set it in security-misc it applies to host and VM.

The f command can be used to kill a process taking up too much memory which might be useful to save the system from crashing.

Could this be abused too to kill important processes?

HulaHoop · January 22, 2020, 7:38pm

In my experience this command does fuck all. I end up using a hotkey combo and click the frozen app window to shut it off.

The only useful one is the the emergency shutdown.

madaidan · January 22, 2020, 8:08pm

See Linux Magic System Request Key Hacks — The Linux Kernel documentation

We can set the bitmask of allowed functions. If we just want the shutdown function, we can set the sysctl to 128.

If we want to set the default in the kernel config, we change CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE to be the bitmask in hexadecimal form.

Yes.

Patrick · January 23, 2020, 3:36am

madaidan via Whonix Forum:

Patrick:

Not sure how fine granular we can whitelist whatever we want?

See Linux Magic System Request Key Hacks — The Linux Kernel documentation

I see. However, it doesn’t look very flexible. We can’t pick and choose
any arbitrary combination of commands?

We can set the bitmask of allowed functions. If we just want the shutdown function, we can set the sysctl to 128.

Could you please white list SAK and shutdown?

If we want to set the default in the kernel config, we change CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE to be the bitmask in hexadecimal form.

Better a security-misc sysctl.

madaidan · January 31, 2020, 5:07pm

Not specific commands. Only groups of commands.

madaidan · February 11, 2020, 6:16pm

This shows more ways to remotely trigger sysrq.

madaidan · February 14, 2020, 6:13pm

Why not both? CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE can still be overridden at runtime via the sysctl. It just sets the default.

madaidan · February 14, 2020, 6:26pm

Patrick · February 15, 2020, 10:43am

madaidan via Whonix Forum:

Restrict the SysRq key by madaidan · Pull Request #60 · Kicksecure/security-misc · GitHub

Restrict the SysRq key by madaidan · Pull Request #43 · Kicksecure/hardened-kernel · GitHub

Awesome! Merged.

madaidan · February 15, 2020, 5:36pm

Did you miss Restrict the SysRq key by madaidan · Pull Request #43 · Kicksecure/hardened-kernel · GitHub?

Patrick · February 15, 2020, 7:42pm

Yes, now merged.

Patrick · December 1, 2020, 1:49pm

Patrick · December 2, 2020, 11:48am

Is SysRq tamed enough currently?

Patrick · December 2, 2020, 1:07pm

Quote https://www.kernel.org/doc/Documentation/SAK.txt

Why?

Because…

It is only available if the kernel was compiled with sysrq support.

?

Just because SysRq isn’t universally available on all Linux distributions isn’t any reason to go for that?

madaidan · December 5, 2020, 5:35pm

Yes. security-misc restricts it sufficiently.

Patrick · November 4, 2023, 2:48pm

Current status:

Restricts the SysRq key so it can only be used for shutdowns and the Secure Attention Key.

Suggested changed:

Recently this discussion was reopened and it has been suggested to completely disable SysRq.

github.com/Kicksecure/security-misc

Disable SysRq by default

Kicksecure:master ← monsieuremre:sysreq

opened 01:38PM - 02 Nov 23 UTC

monsieuremre

+2 -5

I have read the thread and I can see why you chose the leave [SysRq enabled for …reboot/poweroff](https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html). I'll see your situation and I'll raise you a situation. Having the SysRq value fixed at 128 is, tho better than 1, not that poqerful. Firstly, we provide those with local access infinite debugging capabilities, and some real capabilities. >It is a 'magical' key combo you can hit which the kernel will respond to regardless of whatever else it is doing, unless it is completely locked up. And more over, we get no real benefit from it. * Firstly, we dont even use it regularly, at least for the expected use cases here, let's be honest. This is no magical automatic protection. Do you use SysRq to kill every process ever except your current console before logging in? Probably not if you are on a desktop environment. * Secondly, we don't need to use it, anyway. It is 2023. Long gone are the days where random schmos could spy on your keyboard strokes. On wayland, no one can spy on your password key strokes anyway. And this is a real solid solution. Migrating to wayland. Random theoretical work arounds like this bring no real benefit at all because: * it is no good if you don't use the functionality * if you always use it, your life will be very impractical * if you want to use it when you suspect you have malware, well, since malware does not announce itself, you are really not protected from anything unless you preemptively know when there is malware, which if you can do that, you probably don't need this Theoretically yes, this can be a useful, maybe when you are recovering a system. But this is also very unlikely to happen, and there are other, infinetely more secure methods of recovering your system, like livebooting. Also what you discuss in the thread, which is login spoofing on the login screen, is already really unlikely and very difficult to pull off anyway. There is literally nothing running at that point. Something like a rootkit would be capable of such a threat. And a serious and real protection against that is not enabling SysRq and hoping you would preemptively recognize it, but rather using verified boot. And for the use case we leave here, which is shutting the system down with a key combo, I also don't see no need for. If you need magical key combo to shutdown, it is the poweroff button. There are of course certain benefits to doing it this way and stuff but as I said, I don't see these miniscule benefits outweighing the downsides. I might be wrong. If I actually am wrong, please correct me. Convince me why this is better. But I think my points stand.

Patrick · November 26, 2023, 6:12am

This is now in the testers repository.