[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

SysRq (Magic SysRq key)

https://web.archive.org/web/20081011084822/http://kernel.org/doc/Documentation/sysrq.txt

1 Like

Quote Screen Locker (In)Security - Can we disable these at least 4 backdoors?

What does 176 value for /proc/sys/kernel/sysrq mean? Anyone can find documentation for that?

1 Like

Why use wayback?

The docs are still available. They’re just in the admin-guide directory.

https://www.kernel.org/doc/Documentation/admin-guide/sysrq.rst

It allows only rebooting, syncing and remounting all drives read-only with the sysrq key. Sysrq uses a bitmask to control which features to allow.

According to the kernel docs, 16 is sync, 32 is remount read-only and 128 is reboot/poweroff. 16 + 32 + 128 = 176

1 Like

Against link rot and couldn’t find the current version.

2 Likes

4 posts were split to a new topic: Send SysRq commands to VirtualBox usability helper - virtualbox-send-sysrq

Now that untrusted root is in our threat model, we might want to look at disabling SysRq again as abusing it can be done remotely by root (/proc/sysrq-trigger or /dev/uinput).

CLIPOS also recommends to disable this.

1 Like

Would it make sense to add this to apparmor-profile-everything? Since only apparmor-profile-everything implements untrusted root? security-misc alone doesn’t implement untrusted root?

Can’t find. Any reference?

1 Like

apparmor-profile-everything doesn’t really have anything to do with sysrq or other kernel hardening.

I don’t think we should make this related to apparmor.

It does a bit.

It disables kexec.

Hides kernel symbols from root.

Prevents root processes from creating coredumps.

Hardens the BPF JIT compiler for root (that’s what bpf_jit_harden=2 does).

https://docs.clip-os.org/clipos/kernel.html#kernel-hacking

2 Likes

Without apparmor-profile-everything, a malicious root can just easyly enable sysrq as per instructions. There for users who only use security-misc don’t benefit from this. Only hinders debugging for these. Therefore I think this fits better into apparmor-profile-everything. Only with apparmor-profile-everything we can have a complete untrusted root implementation.

2 Likes

Not necessarily. An attacker running as root without read-write access to /proc/sys/kernel/sysrq (as is the case for many systemd services due to ProtectKernelTunables for example) can still be limited by this.

1 Like

madaidan via Whonix Forum:

Not necessarily. An attacker running as root without read-write access to /proc/sys/kernel/sysrq (as is the case for many systemd services due to ProtectKernelTunables for example) can still be limited by this.

In that situation could a compromised process simulate pressing sysrq key?

1 Like

Yes, should be possible via /dev/uinput.

2 Likes

Alright. Then unfortunately sysrq restriction is required.

2 Likes

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?

1 Like

Need SAK for https://www.whonix.org/wiki/Root#Prevent_Malware_from_Sniffing_the_Root_Password

Anything else that makes sense?

1 Like

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.

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

madaidan via Whonix Forum:

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?

1 Like

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.

1 Like

See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html#how-do-i-enable-the-magic-sysrq-key

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.

madaidan via Whonix Forum:

See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html#how-do-i-enable-the-magic-sysrq-key

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.

2 Likes
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]