Kernel Hardening

Patrick · January 13, 2020, 5:09pm

madaidan via Whonix Forum:

Now that we’re working on untrusted root, we might want to set ptrace_scope to 3 but this will break a ton of useful debugging tools like strace.

github.com

Whonix/security-misc/blob/master/etc/sysctl.d/ptrace_scope.conf

## Copyright (C) 2019 - 2019 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.

## Restricts the use of ptrace to root. This might break some programs running under WINE.
## A workaround for WINE would be to give the wineserver and wine-preloader ptrace capabilities. This can be done by running:
##
## sudo apt-get install libcap2-bin
## sudo setcap cap_sys_ptrace=eip /usr/bin/wineserver
## sudo setcap cap_sys_ptrace=eip /usr/bin/wine-preloader
kernel.yama.ptrace_scope=2

already breaks strace. I had to use sudo sysctl -w kernel.yama.ptrace_scope=0 so I could use strace.

If something is not useful on it’s own for security-misc package (?),
add to apparmor-profile-everything package?

Maybe we should invent a package debug (not installed by default)
which ships config snippets which resets to normal debug
kernel.yama.ptrace_scope=0, kernel.sysrq=1 and what not?

madaidan · January 13, 2020, 5:15pm

Only for non-root users. Run strace as root and it works fine.

Setting ptrace_scope to 2 restricts ptrace to root only, setting it to 3 denies access to ptrace entirely.

This would still be useful regardless if apparmor-profile-everything is used.

It would be preferable if it sets ptrace_scope to 2 as that still allows ptrace but only for root. ptrace is really dangerous is it gives malware an easy way to compromise any program in a user’s session. Disabling ptrace_scope wouldn’t be the best.

kernel.sysrq=1 is not the default. Dunno what Debian sets it to though.

madaidan · January 13, 2020, 9:06pm

Patrick · January 14, 2020, 2:13pm

A package debug which isn’t installed by default is a tool which must be as useful as possible for me. In past there was a situation where I needed to use strace to debug an application which should not be run as root (GUI application). Installing a debug package and then still needing to fiddle more (relax more settings) seems not useful for me. In Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection I experienced a hard to debug issue which required serial console and SysRq. It wasn’t easy to set up a debug environment to gather any useful output. If it’s already hard for me as a developer, than I can only imagine how hard it would be for advanced users or new developers trying to debug something. Therefore there need to be strong development tools. A trigger someone can pull (superroot) sudo apt install debug to have access to unrestricted debugging. To debug something isn’t the most visible, rewarding task anyhow but having roadblocks on the way makes it even less likely someone could be bothered to look.

Indeed.

Patrick · January 14, 2020, 2:56pm

madaidan via Whonix Forum:

https://github.com/Whonix/security-misc/pull/54

Merged.

Patrick · January 15, 2020, 11:10am

madaidan via Whonix Forum:

https://github.com/Whonix/security-misc/pull/53

Merged.

Could you please also process /etc/sysctl.conf? I personally don’t
like /etc/sysctl.conf file since there is /etc/sysctl.d folder but
this is required for consistency. /etc/sysctl.conf is still used by
many sysadmins and in many security guides.

Should we disable the systemd-sysctl service and apparmor profile in apparmor-profile-everything now?

I don’t know. Does that that work? The less code, the better. I guess
it’s no longer needed since no sysctl would be changed anyhow since
these get applied even already in initial ramdisk? systemd-sysctl trying
to re-enforce already existing settings wouldn’t require any permissions?

On the other hand, is it OK to say apparmor-profile-everything depends
on security-misc? Would that be the case?

madaidan · January 15, 2020, 8:14pm

Yes. I’ve tested it.

The main reason for this is so we can get rid of the systemd-sysctl profile so even if systemd-sysctl is compromised, it can’t change sysctls.

Yes. Most apparmor-profile-everything users will be using security-misc anyway.

madaidan · January 15, 2020, 8:31pm

Patrick · January 15, 2020, 8:56pm

madaidan via Whonix Forum:

Patrick:

Could you please also process /etc/sysctl.conf ? I personally don’t
like /etc/sysctl.conf file since there is /etc/sysctl.d folder but
this is required for consistency. /etc/sysctl.conf is still used by
many sysadmins and in many security guides.

https://github.com/Whonix/security-misc/pull/55

Merged.

Dunno what initramfs does if a script fails? If sysctl fails, we should
probably not break the boot? To be on safe side, I added this:

(unless you have ideas for more explicit error handling)

madaidan · January 15, 2020, 8:58pm

If one script fails, it shouldn’t break boot.

Patrick · January 22, 2020, 12:09pm

Patrick · January 28, 2020, 7:53am

This wasn’t conclusive debug output.

sudo dmesg | grep lkrg

[   89.832261] p_lkrg: loading out-of-tree module taints kernel.
[   89.850921] p_lkrg: module verification failed: signature and/or required key missing - tainting kernel
[   89.852290] [p_lkrg] Loading LKRG...
[   91.952994] [p_lkrg] LKRG initialized successfully!
[   92.017905] [p_lkrg] Disabling MSRs verification during CI.
[   92.047093] [p_lkrg] [ED] New pCFI configuration => 1 (No stackwalk (weak))
[  510.949628] [p_lkrg] <Exploit Detection> !!! BLOCKING UMH !!!
[  510.949632] [p_lkrg] <Exploit Detection> Someone is trying to execute file: [/bin/false]
[  510.949633] [p_lkrg] <Exploit Detection> --- . ---

sudo sysctl -a | grep lkrg

lkrg.block_modules = 0
lkrg.ci_panic = 0
lkrg.clean_message = 0
lkrg.enforce_msr = 0
lkrg.enforce_pcfi = 1
lkrg.force_run = 0
lkrg.hide = 0
lkrg.log_level = 1
lkrg.random_events = 1
lkrg.smep_panic = 1
lkrg.timestamp = 15
lkrg.umh_lock = 0

grep -r /bin/false /etc/modprobe.d

/etc/modprobe.d/vivid.conf:install vivid /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install dccp /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install sctp /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install rds /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install tipc /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install n-hdlc /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install ax25 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install netrom /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install x25 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install rose /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install decnet /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install econet /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install af_802154 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install ipx /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install appletalk /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install psnap /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install p8023 /bin/false
/etc/modprobe.d/uncommon-network-protocols.conf:install p8022 /bin/false
/etc/modprobe.d/blacklist-dma.conf:install firewire-core /bin/false
/etc/modprobe.d/blacklist-dma.conf:install thunderbolt /bin/false
/etc/modprobe.d/msr.conf:install msr /bin/false
/etc/modprobe.d/blacklist-bluetooth.conf:install bluetooth /bin/false
/etc/modprobe.d/blacklist-bluetooth.conf:install btusb /bin/false

At least I’d like to know which module specifically was refused loading.

Instead of install vivid /bin/false I tried install vivid /bin/false vivid. I.e. passing a parameter to /bin/false which would be ignored by /bin/false but useful to see in logs. That didn’t work. LKRG won’t show it.

It was security-misc kernel.core_pattern=|/bin/false

Therefore what do you think about changing /etc/modprobe.d/vivid.conf from

install vivid /bin/false

to

install vivid /bin/false_vivid

To a non-existing binary.

Any reason against that?

Patrick · January 30, 2020, 11:23am

I’ve renamed / merged some files in security-misc to make these easier to overrule from debug-misc opt-in package to easily enable debugging.

madaidan · January 31, 2020, 5:18pm

If an attacker somehow controls /bin/false_vivid, they can execute arbitrary code as root.

Dunno if an attacker can reasonably control that file though.

Patrick · January 31, 2020, 5:24pm

Attackers have exactly as much or as little control over /bin/false too?

The sysctl early loading inspired me. Would it make sense to load some kernel modules more early in initramfs too? initramfs supports force_load.

force_load

adds a module (and its dependencies) to the initramfs image and also
unconditionally loads the module during boot. Also supports passing arguments to
the module by listing them after the module name.

Useful kernel modules come to mind could be jitterentropy_rng and LKRG [1]. Others?

[1] Though LKRG latter needs to be discussed here Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection and/or with upstream due to complexities.)

madaidan · January 31, 2020, 5:31pm

/bin/false already exists and has its permissions correctly set.

I don’t really like the idea of it pointing to an unknown file. What if /bin/false_vivid already exists but with 777 perms? An attacker can write whatever they want there and it will be regularly executed as root.

jitterentropy should be built-in, not a module. We already do that with hardened-kernel though.

LKRG and tirdad should be loaded as early as possible. Preferably, they would also be built-in but that’s not supported (yet?).

Patrick · February 1, 2020, 1:30pm

Patrick:

Attackers have exactly as much or as little control over /bin/false too?

/bin/false already exists and has its permissions correctly set.

I don’t really like the idea of it pointing to an unknown file. What if /bin/false_vivid already exists but with 777 perms?

Nothing in /bin does ever exist (without previous system compromise or created by system administrator) that has permissions 777 (i.e. writeable by others than root). Any argument against /bin/false_vivid could also be made against /bin/false.

An attacker can write whatever they want there and it will be regularly executed as root.

Patrick:

Useful kernel modules come to mind could be jitterentropy_rng and LKRG [1]. Others?

jitterentropy should be built-in, not a module. We already do that with hardened-kernel though.

Alright.

However, as long as we’re not using hardened-kernel by default and for non-users of hardened-kernel, does it make sense the load jitterentropy_rng more early?