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

Kernel Hardening

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

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 https://redmine.tails.boum.org/code/issues/17236 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.

https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux-hardened#n9814

https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux-hardened#n10248

Also see https://outflux.net/blog/archives/2019/11/14/security-things-in-linux-v5-3/

2 Likes

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

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

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

Good point.

Here is a related bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

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.

http://git.annexia.org/?p=virt-mem.git;a=blob;f=lib/virt_mem_kallsyms.ml;h=9e6eccb6629a2ea067ee46a7c690aea17e44c0d2;hb=HEAD#l39
http://git.annexia.org/?p=virt-mem.git;a=blob;f=lib/virt_mem_ksyms.ml;h=8a38caec5b9fa05904c3b9e8b5fcdb76871f27ae;hb=HEAD#l29

  • ^ -> 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

Something here that we don’t have yet? https://trent.utfs.org/wiki/Hardening/Linux

1 Like

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

Yes. Could you implement this please?

1 Like

https://trent.utfs.org/wiki/Hardening/Linux#Permission_lockdown and https://trent.utfs.org/wiki/Hardening/Linux#.2Fproc (apparmor is probably a far better way to restrict access to /proc anyway as we can remove access for files entirely) look interesting.

I’ve been thinking of hardening file permissions for a while but don’t have many ideas except restricting /boot.

There is also more here https://wiki.archlinux.org/index.php/Security#File_access_permissions

1 Like

Where? Maybe https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/permission-lockdown or /etc/kernel/postinst.d? permission-lockdown can also be used for other file permission hardening.

Should be sufficient in the security-misc postinst script. If “others” aren’t allowed to read /boot and if only members of group “boot” and root can read /boot, I doesn’t have to be reapplied again and again. Could be protected by a do_once status file to allow easier customization (undo by sysadmin).

1 Like

If we must. If not avoidable through more efficient / appropriate solution. That script runs a lot. Could slow down performance. Would require multiple status _done files.

1 Like

Changing permissions wouldn’t slow down performance much.

We could do this instead:

if ! [ "$(stat -c %a /boot/)" = "700" ]; then

If you want it to be configurable, we can create a /etc/permission-lockdown.d folder for user configurations.

1 Like

The idea of the _done file to do this one once and then don’t bother the sysadmin with it anymore.

More error prone. This might work now (untested) but could break as distribution change things. Better to just run the commands to set the right permissions.

It’s already configurable though sudo pam-auth-update (then disable permission lockdown by security-misc) if someone ever asks about it. Not sure further configurability is required.

I don’t like https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/permission-lockdown much. It runs every time “sudo” runs or someone logins. Whenever pam is being invoked. Therefore spams systemd journal. Back then I didn’t have better ideas to implement it so permissions for existing users (those who upgrade) will be locked down.

My thinking maybe was: permission-lockdown cannot run only at postinst - since during build time, no /home/user folder exists. It is created during first login using pam mkhomedir.

Perhaps permission-lockdown could

  • run at postinst to lockdown existing user’s home folders.
  • And then pam mkhomedir with umask= parameter could create new home folders (at first boot time) with already locked down permissions.

(locked down meaning: “others” cannot read. Not “world” readable.)

However, for purposes of locking down /boot, I think that is perfectly doable from security-misc postinst?

https://github.com/Whonix/security-misc/blob/master/debian/security-misc.postinst

1 Like

I meant allowing people to choose to disable/enable /home, /boot etc. restrictions (once they’re added) as they wish.

I would prefer to have something periodically check and restrict /boot in case the permissions get changed for whatever reason. If a user wants to have the permissions changed, they can disable permission-lockdown (or change specific settings like I said above).

1 Like

Since it’s only done once (and by the time they want to change the setting that setting is already turned on), it’s even easier for them to just change the permissions back to what they want. Thanks to the _done file, the sysadmin won’t be bothered with this ever again.

Why would anything package work on permissions on folder /boot directly? Or what else could change it?

Even if permissions for things inside folder /boot/something change (Debian deciding to change permissions for kernel image or something), that file would stay inaccessible since the root of the folder (i.e. /boot) already has the correct permissions.

If it should be something more periodic…More enforcing…
(Yet configureable. (?))
(And “non-opaque”.)
What about systemd’s /usr/lib/tmpfiles.d mechanism? Also looks quite appropriate?
(No, not just temp files. Yes, some files there configure permissions for persistent folders such as /var/log or /var/cache.)
Would that work?

1 Like

What if they don’t remember what the permissions were or aren’t technical enough to change them back to what they want?

I think it would be good to save the default permission and reset it if the user chooses too.

Just in case. E.g. a user’s mistake or misconfigured script can do that.

You wouldn’t want accidental read-write access to kernel images.

Permissions may be more likely to change for other folders we might restrict in the future.

That looks great actually. Seems like a far better approach.

1 Like

OpenSUSE actually has a package that changes the file permissions.

https://en.opensuse.org/openSUSE:Security_Documentation

  • the easy profile has a focus on ease of use where more program features work out of the box without the user having to intervene. It also means that there is a larger security attack surface. It can be used for typical single user desktop systems when usability is favored over stricter security.
  • the secure profile is more security oriented and disables certain program privileges. This can result in some program features not being available or behaving less conventiently. It can be used for typical server or multi-user host machines.
  • the paranoid profile is a tightly locked down set of settings that isn’t fully usable in production, because a lot of program features will stop working. This should only be used when security is the major requirement and when you are willing to tune the profile into a state where you can perform the task you want to fullfill with the system.

I can’t find the permissions file anywhere online to see what they do. I’ll setup a VM to check.

1 Like

Here is opensuse’s configuration.

permissions.secure: https://paste.debian.net/hidden/872cc5ed/

permissions.paranoid: https://paste.debian.net/hidden/9cc67712/

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