Page MenuHomePhabricator

set kernel.printk sysctl to prevent kernel info leaks
Open, NormalPublic

Description

quote @madaidan:

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.

dmesg --console-off does not do the trick.

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.

Edit:
Setting kernel.printk = 3 3 3 3 was implemented in /etc/sysctl.d/30_security-misc.conf and it is being set initramfs before systemd has started using /etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs.


Maybe from Linux 5.7+ sysctls can be set from Linux boot cmdline which is planned as per T984 which might fix the remaining unwanted messages.


https://wiki.archlinux.org/index.php/Silent_boot

Details

Impact
Normal

Event Timeline

Patrick triaged this task as Normal priority.Dec 23 2019, 2:19 PM
Patrick created this task.

Should this be set in the initramfs?

Some logs are shown before systemd-sysctl executes so using /etc/sysctl.d/ may not be enough.

Yes. Probably both. initramfs for apparmor-profile-everything users and
/etc/sysctl.d/ security-misc.

Why not use an initramfs hook in security-misc? Not everyone will have security-misc and apparmor-profile-everything installed. Users with just security-misc installed will still have some kernel logs shown during early boot.

I guess because a sysctl.d drop-in config file is easy and catches most.
initramfs hook covers only initramfs users. Not dracut. But
security-misc initramfs hook sounds good enough. dracut support can
come later, if ever. Please implement.

We can use a sysctl.d drop-in and an initramfs hook in security-misc so non-initramfs users will still be mostly protected.

Sounds good.

Still wondering if initramfs modification this can be avoided... Still wondering if kernel.printk can be set through a kernel parameter. Looking again at https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt...

Would the following kernel parameter(s) reach the same goal?

  • printk.devkmsg=off
  • loglevel=0
  • quiet

Just now asked:
How to set sysctl using kernel comand line parameter?

Could you please add a feature to easily enable debugging?

What is THE kernel option for "more verbose, debug"? debug? ignore_loglevel? Such as if kernel parameter debug is set, do not use kernel.print in initramfs. Just exit.

Then I could add debug to grub-output-verbose as kernel parameter. (That package is in next version no longer installed by default.) (And that package is useful at least for me to easily enable debugging.)

grub-output-verbose could also drop a snippet which deactivates what /etc/sysctl.d/printk.conf does and reset kernel.print to default or even higher level.

printk.devkmsg=off

This just prevents writing to /dev/kmsg. It doesn't stop kernel logs being displayed during boot.

loglevel=0
quiet

Dunno about these. Need to be tested.

Could you please add a feature to easily enable debugging?

Should I check for the debug kernel parameter or something else?

Patrick updated the task description. (Show Details)Dec 25 2019, 10:38 AM
Patrick updated the task description. (Show Details)

quiet

quiet (Debian default :)) works really well. After sudo apt purge grub-output-verbose and sudo update-grub [1] this is all I am seeing on a VirtualBox serial console.

Loading Linux 4.19.0-6-amd64 ...
Loading initial ramdisk ...
[ 2.093532] sd 4:0:0:0: [sda] Incomplete mode parameter data
[ 2.099586] sd 4:0:0:0: [sda] Assuming drive cache: write through
/dev/sda1: clean, 110434/6553600 files, 1300598/26213632 blocks
[ 4.771736] [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.
[ 4.785116] [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.
[ 5.880020] [p_lkrg] Loading LKRG...
[ 6.474864] [p_lkrg] LKRG initialized successfully!
[ 14.679246] ram_adjusted_desktop_starter[1624]: [INFO] If your host has little RAM, you are advised to reduce Gateway RAM to 256 MB. No graphical desktop environment will be started in that case. A Gateway without graphical desktop environment works as good as one with, it's just not that convenient. If you want, you can sometimes start a graphical desktop environment by toggling how much RAM is available to Gateway. Documentation about this feature can be found here: https://www.whonix.org/wiki/Desktop
[ 14.688327] ram_adjusted_desktop_starter[1624]: [INFO] Trying to start login manager (graphical desktop environment) lightdm...


[1] grub-output-verbose should run "sudo update-grub" at removal but does not do yet.

The loader of tirdad is currently using dmesg.

## https://github.com/0xsirus/tirdad/issues/5
## /var/log/kern.log is unsuitable. It can during manual testing i.e.
## 'sudo /usr/lib/tirdad/loader' but not when run through systemctl i.e.
## 'sudo systemctl restart tirdad-dkms'.
## https://phabricator.whonix.org/T950
while read -r line; do
  if echo "$line" | grep --quiet --ignore-case "Installing tirdad hook succeeded" ; then
     exit "$exit_code"
  fi
done < <( dmesg --notime --follow )

Setting kernel.printk=3 3 3 3 with sysctl might break it. Hopefully no longer needed as per my previous post. Something to keep in mind.

In T950#19249, @Patrick wrote:

The loader of tirdad is currently using dmesg.

This is no longer the case.

This issue is fixed now due to the quiet boot parameter. kernel.printk=3 3 3 3 isn't needed anymore.

Patrick closed this task as Invalid.Mar 22 2020, 12:48 PM
Patrick assigned this task to madaidan.

Thanks!

Patrick reopened this task as Open.Mar 22 2020, 7:47 PM

Not fully fixed.

When booting VirtualBox there are still some confusing kernel messages shown. usability issue.

[ 1.993694] sd 0:0:0:0: [sda] Incomplete mode parameter data
[ 1.993836] sd 0:0:0:0: [sda] Assuming drive cache: write through

( https://www.whonix.org/wiki/Dev/VirtualBox#.5Bdrm:vmw_host_log_.5Bvmwgfx.5D.5D_ERROR_Failed_to_send_log )

[ 4.376616] [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.

( https://www.whonix.org/wiki/Dev/VirtualBox#.5Bsda.5D_Incomplete_mode_parameter_data_.2F_Assuming_drive_cache:_write_through )


Above messages probably do not show up in Whonix KVM but if you like to reproduce this general issue then sudo apt install lkrg. Also LKRG shows various confusing messages which should equally apply to Whonix KVM.

[ 3.612811] [p_lkrg] Loading LKRG...
[ 4.069086] [p_lkrg] LKRG initialized successfully!
[ 4.261277] [p_lkrg] ALERT !!! FOUND LESS[1] MODULES IN DB IN MODULE LIST[36] THAN IN CURRENT MODULE LIST[37]
[ 4.261508] [p_lkrg] EXTRA MODULE:
[ 4.261747] [p_lkrg] EXTRA MODULE IS THE SAME AS ON-GOING MODULE ACTIVITY EVENTS
[ 4.261914] [p_lkrg] ALERT !!! FOUND LESS[1] MODULES IN DB IN KOBJ[36] THAN IN CURRENT KOBJ[37]
[ 4.262006] [p_lkrg] EXTRA MODULE:
[ 4.262245] [p_lkrg] EXTRA MODULE IS THE SAME AS ON-GOING MODULE ACTIVITY EVENTS
[ 4.277598] [p_lkrg] ALERT !!! FOUND LESS[1] MODULES IN DB IN MODULE LIST[36] THAN IN CURRENT MODULE LIST[37]
[ 4.277845] [p_lkrg] EXTRA MODULE:
[ 4.278116] [p_lkrg] EXTRA MODULE IS THE SAME AS ON-GOING MODULE ACTIVITY EVENTS
[ 4.278338] [p_lkrg] ALERT !!! FOUND LESS[1] MODULES IN DB IN KOBJ[36] THAN IN CURRENT KOBJ[37]
[ 4.278447] [p_lkrg] EXTRA MODULE:
[ 4.278738] [p_lkrg] EXTRA MODULE IS THE SAME AS ON-GOING MODULE ACTIVITY EVENTS

I see these messages as a symptom. These messages might not leak something interesting but other messages which might be using the same mechanism might contain kernel info leaks.

Should these messages be hidden? How to hide these messages?

And of course these messages are attributed to whatever Whonix issue someone is having.

Maybe from Linux 5.7+ sysctls can be set from Linux boot cmdline. (Related: T984)

Patrick updated the task description. (Show Details)Apr 16 2020, 11:37 AM

/etc/sysctl.d/20-quiet-printk.conf

kernel.printk = 3 3 3 3

followed by sudo update-initramfs -u hides [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message. Which is progress. But does not hide [sda] Incomplete mode parameter data.

Maybe also thanks to sysctl-initramfs.

I've also tested the following values.

kernel.printk = 2 2 2 2
kernel.printk = 1 1 1 1
kernel.printk = 0 0 0 0

These also did hide [drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.but did not hide [sda] Incomplete mode parameter data.

Patrick updated the task description. (Show Details)Apr 16 2020, 2:07 PM

Even kernel parameter quiet loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3
(from https://wiki.archlinux.org/index.php/Silent_boot)
does not hide [sda] Incomplete mode parameter data.

More ideas that don't require kernel recompilation?

Setting quiet loglevel=0 in that exact order as per https://github.com/Whonix/security-misc/commit/6485df8126b52a2072824fa442e8d1dd5cb18981 does now hide [sda] Incomplete mode parameter data. However, messages by LKRG are not yet hidden.

[    5.382817] [p_lkrg] Loading LKRG...
[    5.864095] [p_lkrg] LKRG initialized successfully!
[    6.118039] [p_lkrg] ALERT !!! FOUND LESS[1] MODULES IN DB IN MODULE LIST[39] THAN IN CURRENT MODULE LIST[40]
[    6.118231] [p_lkrg] EXTRA MODULE:
[    6.118477] [p_lkrg] ** EXTRA MODULE IS THE SAME AS ON-GOING MODULE ACTIVITY EVENTS **
[    6.118646] [p_lkrg] ALERT !!! FOUND LESS[1] MODULES IN DB IN KOBJ[39] THAN IN CURRENT KOBJ[40]
[    6.118739] [p_lkrg] EXTRA MODULE:
[    6.118978] [p_lkrg] ** EXTRA MODULE IS THE SAME AS ON-GOING MODULE ACTIVITY EVENTS *

More ideas that don't require kernel recompilation?