Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable SysRq by default #150

Merged
merged 1 commit into from Nov 5, 2023
Merged

Conversation

monsieuremre
Copy link
Contributor

I have read the thread and I can see why you chose the leave SysRq enabled for reboot/poweroff. 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.

@adrelanos
Copy link
Member

I need to re-read the prior discussion how we ended up where we are now:

inviting comments:
https://forums.whonix.org/t/sysrq-magic-sysrq-key/8079/72

@adrelanos
Copy link
Member

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.

The threat model for SAK is if there are multiple non-root users (actual people) sharing the same computer, logging in/out to virtual terminals (VT).

Person A if compromised or malicious could fake to be logged out but actually run a spoofed login to steal login passwords of Person B (which might be another non-root or root user).

The only way to defeat this advanced threat model would be to always use SAK before using login.

This way of sharing computers nowadays does not seem to be very popular anymore. Those who wanted to defeat such a threat model would need to be aware of https://www.kicksecure.com/wiki/Login_spoofing and then act accordingly by always using SAK.

It's actually the same with wayland than with a VT. Person A could pretend to logout while it is actually a spoofed login screen running in full screen mode. Person B would then have their password stolen.

But indeed, a full reboot or better nowadays not even sharing your devices seems a better approach. A spoofed login screen is only 1 of many options locally running malware or an adversary with physical access has.

@adrelanos adrelanos merged commit d9b5d77 into Kicksecure:master Nov 5, 2023
@monsieuremre monsieuremre deleted the sysreq branch November 17, 2023 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants