Kernel Hardening - security-misc

Development
213

During boot, the kernel logs are displayed on the console. As the kernel logs are meant to be restricted to root (kernel.dmesg_restrict=1), this should probably be disabled.

Setting kernel.printk=3 3 3 3 with sysctl configures it so only really important errors will be displayed.

Also see Does printk() cause any security issues?

This can improve boot and shutdown speed too. I’ve noticed that performance improves significantly after setting this.

1 Like
214

Not sure exactly how to solve this but something should be done.

Was contemplating:

dmesg --console-off

Where/when to run that command? That command is per console or user or global?

The context which pointed that out: timesync Error: vgsvcTimeSyncWorker: VbglR3GetHostTime failed - #7 by Patrick_mobile

Also whonixcheck needs lockdown wrt log viewing. Allows users to see log on systemd warning/error/cycle messages. Running whonixcheck should require sudo but as much as possible should run unprivileged.

1 Like
215

I still see some logs after running that. Changing the kernel.printk sysctl hides more. I can still see some logs even with changing kernel.printk as it starts displaying logs before systemd-sysctl is executed. The only way around that would be setting kernel.printk in the initramfs, before systemd has started if it’s even possible.

During security-misc installation and/or a systemd service.

Looks global.

Logs can still be viewed with sudo dmesg. They were never available to unprivileged users in the first place as Debian sets kernel.dmesg_restrict=1 by default.

216

sudo helps?

1 Like
217

I guess that’s ok? Unavoidable? At least sudo/root required.

But whonixcheck shouldn’t show to nonroot/nonsudo users.

1 Like
218

Might be cause or related…?

https://github.com/Whonix/grub-output-verbose/blob/master/etc/default/grub.d/30_output_verbose.cfg

I considered verbose boot a usability feature. Better progress report during boot. Doesn’t look frozen. A lot users think it’s frozen and give up. Also good for debugging / see issues. Might have to reconsider / find alternative.

1 Like
219

No. I ran it as root.

It wouldn’t be too hard to make it only display the logs if the user is root.

1 Like
220

Under the enhanced threat model of hiding as much information from user as possible, user has no business reading most of whonixcheck output. But nontrivial change since whonixcheck also used as connectivity checker / progress meter after ACW.

1 Like
221

Perhaps specifically those are ones that should better be hidden? If anything, hide it all for completeness sake?

1 Like
222

If really important errors are hidden too then users might just see a black screen and have no idea what’s happened.

E.g. a kernel panic happens for whatever reason and important errors are hidden so the user doesn’t know.

1 Like
223
1 Like
224

system.map issue.

sudo make install
make -C /lib/modules/4.19.0-6-amd64/build M=/home/user/sourcesother/lkrg-0.7 modules_install
make[1]: Entering directory ‘/usr/src/linux-headers-4.19.0-6-amd64’
INSTALL /home/user/sourcesother/lkrg-0.7/p_lkrg.ko
DEPMOD 4.19.0-6-amd64
Warning: modules_install: missing ‘System.map’ file. Skipping depmod.
make[1]: Leaving directory ‘/usr/src/linux-headers-4.19.0-6-amd64’
depmod -a
/home/user/sourcesother/lkrg-0.7/scripts/bootup/lkrg-bootup.sh install
[*] Executing LKRG’s bootup installation script
[+] Systemd detected
Installing lkrg.service file under /run/systemd/system folder
Enabling lkrg.service on bootup
Created symlink /etc/systemd/system/multi-user.target.wants/lkrg.service → /run/systemd/system/lkrg.service.
To start lkrg.service please use: systemctl start lkrg
[+]

1 Like
225

We should use the init_on_alloc=1 and init_on_free=1 boot parameters once they get to the Debian stable kernel.

https://lore.kernel.org/kernel-hardening/20190626121943.131390-2-glider@google.com/

init_on_alloc=1 makes the kernel initialize newly allocated pages and heap objects with zeroes.

init_on_free=1 makes the kernel initialize freed pages and heap objects with zeroes upon their deletion. This helps to ensure sensitive data doesn’t leak via use-after-free accesses.

I am not sure what the difference between init_on_free=1 and page_poison=1 is. They seem to do the same.

The link above says

If either SLUB poisoning or page poisoning is enabled, we disable
init_on_alloc and init_on_free so that initialization doesn’t interfere
with debugging.

So I’m not sure which to use.

There is a Tails ticket for this Enable the init_on_alloc=1 and init_on_free=1 Linux options (#17236) · Issues · tails / tails · GitLab and they also use page_poison=1 so we should wait and see what they say.

linux-hardened seems to prefer init_on_free over page_poison.

Also see security things in Linux v5.3 « codeblog

2 Likes
226

The program doesn’t work for me but it has a neat list of areas to look for kernel symbols.

I can’t find any kernel symbol leaks in these directories/files but it lists the kernel images and I don’t know how to check those for symbols.

Why are the kernel images readable by all users anyway? Shouldn’t it be restricted to root?

1 Like
227

Linus Torvalds has also said interesting things about these leaks.

https://www.openwall.com/lists/kernel-hardening/2017/10/05/5

And yes, as Kees and Daniel mentioned, it’s definitely not just dmesg. In fact, the primary things tend to be /proc and /sys, not dmesg itself.

Another example of this would be commit 31b0b385f69d (“nf_conntrack: avoid kernel pointer value leak in slab name”), where the fact that the slab name had a pointer in it leaked it in the filenames in /sys, because we export slab statistics under /sys/kernel/slab/. And each file was readable only by root, but the file names were readable by everybody.

The full system apparmor profile gives fine-grained access to /sys and /proc so that would make kernel pointer leaks very unlikely.

2 Likes
228

A post was merged into an existing topic: kernel recompilation for better hardening

230

Good point.

Here is a related bug report:

Summary:

  • Ubuntu seems to harden this already.

Kees Cook (kees) wrote on 2011-04-25: #3

This mode change is “by design”. For local admins that what to relax this restriction, you can use dpkg-statoverride:

sudo dpkg-statoverride --add root root 0644 /boot/vmlinuz-$(uname -r) --update

To have this automatically happen with each new kernel, create /etc/kernel/postinst.d/statoverride:

.

#!/bin/sh
version="$1"
# passing the kernel version is required
[ -z "${version}" ] && exit 0
dpkg-statoverride --add root root 0644 /boot/vmlinuz-${version} --update
  • breaks some KVM use cases

It is fairly common practice to boot kvm or qemu with something like:
kvm -kernel /boot/vmlinuz-$(uname -r)

  • It might break simpler malware relying on this. It wouldn’t break more sophisticated malware - for that we couldn’t use a public kernel image - kernel would have to be (automatically) re-compiled at user’s machine (kernel recompilation for better hardening) ([+ have different entry / kernel symbol locations, of course. If we’re unlucky, the user would reproducible compile the very same kernel?].

Richard W.M. Jones (rich-annexia) wrote on 2011-04-26: #5

What is being protected by this mode change? This kernel is distributed
on hundreds of mirrors – there is no secret in here.

Kees Cook (kees) wrote on 2011-04-26: Re: [Bug 759725] Re: The kernel is no longer readable by non-root users

The mode changes do not protect a system from any dedicated attacker (for
the reason you state), but it does have real-world benefits against
simplistic kernel exploitation (keeping kernel symbols away from non-root
users). It is absolutely a trade-off.

Kees Cook (kees) wrote on 2011-04-26:

I am not saying they’re hidden from being looked up externally (just fetching the kernel package’s System.map file is easiest). But because the symbols can be extracted in the way you point out is why the kernel image itself needs to be unreadable. This change is to block the class of attacks carried out by script kiddies and automated systems that expect to be able to look up symbols locally and make exploits totally portable to all kernel versions. It changes the nature of future attacks, at least forcing attackers to take additional steps.

  • might break guestmount / libguestfs
  • might affect OpenStack
  • might break tftpd serving /boot to netboot clients
  • might break hobbit-plugins (whatever that is)

Richard W.M. Jones (rich-annexia) wrote on 2011-04-26: #8

By the way, I myself actually wrote code that walks through the kernel memory
finding the location of the symbols. You’re not gaining any extra security by
making this change, but you are making Ubuntu less useful.

annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_kallsyms.ml
annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_ksyms.ml

  • ^ → User should not have access to /proc/kallsyms too? Doable? Any side effects? Then we can protect from above enumeration too.

I would go as far as saying that non-root users by default shouldn’t be able to read any file in /boot? Let’s use dpkg-statoverwrite or something to restrict access so only members of linux group boot can read it?

  1. create linux group boot (or similarly named?) → Port to sysusers.d mechanism?

sudo chgrp --recursive boot /boot

sudo chmod --recursive o-r /boot
1 Like
231

Something here that we don’t have yet? Hardening/Linux - Segfault

1 Like
232

Those only seem to be for the host so won’t apply to Whonix VMs.

Not needed. kernel.kptr_restrict=2 already fixes this exact issue. Run cat /proc/kallsyms and you’ll see all addresses have been replaced with 0000000000000000.

Making it unreadable won’t have any advantage.

I would agree with that.

1 Like
233

Yes. Could you implement this please?

1 Like