SysRq (Magic SysRq key)

[Patrick]

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

[Patrick]

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

@Patrick

A lot ways to disable the screensaver.

We might have to reconsider SysRq (Magic SysRq key) as per:

Backdoor #3: Alt-SysRq-F .

This is the Linux kernel “OOM-killer” keystroke. It shoots down random long-running programs of its choosing, and so might might target and kill xscreensaver, and there’s no way for xscreensaver to protect itself from that. You can disable it globally with: sudo ‘echo 176 > /proc/sys/kernel/sysrq’

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

[madaidan]

@Patrick

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

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

@Patrick

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

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

[Patrick]

@madaidan

Why use wayback?

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

[madaidan]

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.

[Patrick]

@madaidan

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).

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?

@madaidan

CLIPOS also recommends to disable this.

Can’t find. Any reference?

[madaidan]

@Patrick

Would it make sense to add this to apparmor-profile-everything? Since only apparmor-profile-everything implements untrusted root?

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.

@Patrick

security-misc alone doesn’t implement untrusted root?

It does a bit.

It disables kexec.

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/kexec.conf

Hides kernel symbols from root.

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/kptr_restrict.conf

Prevents root processes from creating coredumps.

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/suid_dumpable.conf

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

https://github.com/Whonix/security-misc/blob/master/etc/sysctl.d/harden_bpf.conf

@Patrick

Can’t find. Any reference?

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

[Patrick]

@madaidan

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

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.

[madaidan]

@Patrick

Without apparmor-profile-everything, a malicious root can just easyly enable sysrq as per instructions.

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.

[Patrick]

madaidan via Whonix Forum:

@Patrick

Without apparmor-profile-everything, a malicious root can just easyly enable sysrq as per instructions.

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?

[madaidan]

@Patrick

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

Yes, should be possible via /dev/uinput.

Remote executing Magic Sys Rq

[Patrick]

Alright. Then unfortunately sysrq restriction is required.

[madaidan]

@Patrick

Alright. Then unfortunately sysrq restriction is required.

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]

Need SAK for Safely Use Root Commands

Anything else that makes sense?

[madaidan]

@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.

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]

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]

@madaidan

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.

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]

@Patrick

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

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.

@Patrick

Could this be abused too to kill important processes?

Yes.

[Patrick]

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.