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

Kernel Hardening

Not so easy. Will result in an error when reinstalling the package.

sudo rm /boot/System.map-4.19.0-5-amd64
sudo touch /boot/System.map-4.19.0-5-amd64
sudo chattr +i /boot/System.map-4.19.0-5-amd64
sudo apt install --reinstall linux-image-4.19.0-5-amd64

Will just be overwritten on upgrade.

dpkg: error processing archive /var/cache/apt/archives/linux-image-4.19.0-5-amd64_4.19.37-5+deb10u1_amd64.deb (–unpack):
unable to make backup link of ‘./boot/System.map-4.19.0-5-amd64’ before installing new version: Operation not permitted
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
I: /vmlinuz is now a symlink to boot/vmlinuz-4.19.0-4-amd64
I: /initrd.img is now a symlink to boot/initrd.img-4.19.0-4-amd64
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-4.19.0-5-amd64_4.19.37-5+deb10u1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Then it’s also not that hard to hardcode whatever information required from system map into the malware itself (for a few common kernel versions). Looking up required information by parsing system map sounds like a rather advanced attack?

Also path to /boot/System.map-4.19.0-5-amd64 cannot be easily determined. Perhaps by looking parsing apt-file list kernel-package or by using information from uname and dynamically creating the name of the file.

If we create our own kernel package we can wipe that file before creating the package or when users compile their own kernel they can wipe it.

1 Like

I think most malware would attempt to look around certain files on the system instead of hardcoding information or getting them from another source.

An attacker could just run

cd /var/cache/apt/archive; ar x linux-image-$(uname -r).deb; tar -xf data.tar.xz; cat boot/System.map-$(uname-r)

Instead of spending time on manually getting the information for multiple different kernels.

It always ends in the kernel version so you can just use /boot/System.map-$(uname -r).

If this threat model presupposes non-root access, wouldn’t it be enough to just harden linux file access rights? Making system map no longer readable by non-root users? That may even be something upstream might be more easily convinced of doing by default since it would be a great balance between security and debugging?

On topic:

madaidan via Whonix Forum:>

I think most malware would attempt to look around certain files on the system instead of hardcoding information or getting them from another source.

An attacker could just run

cd /var/cache/apt/archive; ar x linux-image-$(uname -r).deb; tar -xf data.tar.xz; cat boot/System.map-$(uname-r)

That’s not a great since the kernel package may or may note be still inside folder /var/cache/apt/archive.

There’s not that many kernel versions. Collecting various boot/System.map-$(uname-r) files (probably just need a few lines of these) and hardcoding into malware does not seem hard to me.

Instead of spending time on manually getting the information for multiple different kernels.

It always ends in the kernel version so you can just use /boot/System.map-$(uname -r).

But that is only known after the kernel was installed and booted. So mount to /dev/null and similar tricks cannot be applied beforehand so it gets never really written.

1 Like

I don’t see why it should presuppose non-root access. What I meant above about shred was local access, not root. Shred would only really help if someone is doing forensics analysis on your hard drive.

madaidan via Whonix Forum:

I don’t see why it should presuppose non-root access. What I meant above about shred was local access, not root. Shred would only really help if someone is doing forensics analysis on your hard drive.

A lot mixed in here to easily talk past each other.

system map access generally:

root compromise: If there is root access (root user compromise from
remote), why would anyone still care about system map?

non-root user compromise: I.e. a malware process is running under a
linux user account such as user apache2 or so. In that case, the malware
being unable to read system map, might help to prevent the attacker from
escalating to compromise.

If these assumptions are right, then setting access rights to system map
to root only would complicate non-root to root escalation for malware.

system map file recovery by malware:

File recovery tools can be run root or non-root users?

If only by root users: great.

If also by non-root users: bad, because then malware could use undelete
tools to re-creating system map file.

File recovery tools don’t necessarily require local (as in hands on) access.

1 Like

It doesn’t necessarily have to be full root access. It could just be e.g. a compromised service with only CAP_DAC_OVERRIDE. Many do use that capability.

Oh, I’ve never messed around with those before and I thought they required local access.

If the system map files can be recovered remotely, then we can just switch the rm with shred -zu in the script.

1 Like
1 Like

Could you please have a look here?

https://outflux.net/blog/

1 Like
1 Like

Most seem to be kernel config options. Not things that can be changed via sysctl or boot parameters.

One that does look interesting though is page_alloc.shuffle=1 although this is only for later kernel versions. Debian will likely enable this by default once it comes.

There’s nothing here we don’t already do or would require a custom kernel.

Also, Copperhead is not a good source anymore after they kicked out Daniel Micay and started scamming users.

2 Likes

Indeed.

perhaps it is more efficient to tell ujpstream to not include map files in the package?

Does removing them add any protection for a publicly compiled kernel anyhow?

2 Likes

madaidan via Whonix Forum:

There’s nothing here we don’t already do or would require a custom kernel.

Also, Copperhead is not a good source anymore after they kicked out Daniel Micay and started scamming users.

I didn’t follow these developments. However, possibly these these
websites are still the same as created by Daniel Micay and never updated
since. Also, we’d use them as as inspiration (like from any source
anyway), and then independently verify all claims (before we make
changes on our side) not for face value.

1 Like

@onion_knight wrote in VMs do no start until the CPU configuration is set to “Copy host CPU configuration”

3 posts were merged into an existing topic: enable Linux kernel gpg verification in grub and/or enable Secure Boot by default

1 Like

Something useful here?

1 Like

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

I just wanted to point out in folder /etc/default/grub.d/40_kernel_hardening.cfg, there is this entry: “slab_debug=FZP”
Should it be “slub_debug=FZP” instead?

3 Likes

Yes, thanks! I don’t know how we overlooked that.

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