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

Kernel Hardening

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

@madaidan can you also exempt sysrq + f from being blocked?

This key is particularly useful when killing a hanging process considering swap is disabled on the host for Whonix live mode to be traceless.

Call oom_kill, which kills a process to alleviate an OOM condition f

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

I don’t see how this is any better than just using Ctrl + C or kill -9.

They likely won’t want to do that as the map files are good for debugging.

It would protect against malware attempting to check for local files instead of having to use another source.

1 Like

sysrq is immediately applied when the whole machine is stalled and you can’t really open a terminal and type anything. Also isn’t Ctrl + C just the copy command?

2 Likes

Ctrl + C seems fine for that then.

No, Ctrl + C sends the SIGINT command to kill a process. For example, run yes in a terminal and press Ctrl + C to kill it. Ctrl + D can also be used to kill an open terminal.

1 Like

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

madaidan via Whonix Forum:

Ctrl + C seems fine for that then.

When the whole machine appears frozen Ctrl + C won’t have any effect.
sysrq might work.

2 Likes

Of course, but we shouldn’t be too trusting of Copperhead.

If Ctrl + C doesn’t work, I doubt sysrq would.

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

sysrq is immediately enforced by a running kernel. That’s what makes these commands so special. If there isn’t a security argument against it, please add it to the mask.

1 Like

Can a user only kill it’s own processes with it or any process?

What if an unprivileged user kills a very important process that is usually only accessible by root?

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