Prerequisite: ask upstream how this file is created.
Next step, if above step doesn’t find a solution: an inotify based
rather than time based implementation.
whonix-firewall /usr/lib/whonix-firewall/firewall-restarter uses
inotify. (So does msgcollector.)
apt-file list linux-image-4.19.0-5-amd64 | grep System
linux-image-4.19.0-5-amd64: /boot/System.map-4.19.0-5-amd64
dpkg -S /boot/System.map-4.19.0-5-amd64
linux-image-4.19.0-5-amd64: /boot/System.map-4.19.0-5-amd64In other words, system map file is shipped as a usual file by the Debian kernel package.
To remove it more effectly we could have a hook in /etc/kernel/postinst.d folder which calls /usr/lib/security-misc/remove-system.map (failing open).
A duplicate of system map file could still be on the disk in /var/cache/apt/archives/ folder. (apt cached package) Other duplicates could be there when using an apt-cache. It could be recoverable unless we use shred. And even then it could be recoverable from swap or so?
Also, contents of this system map are public knowledge - since easily re-downloadable from packages.debian.org.
What kernel version we are using is easily knowable anyway with uname -a (and likely also through standard API and other ways?).
So I am wondering if any efforts to delete system map are worth anyhow? Maybe that is more useful for people who compile their own kernels (therefore using own randomization)? If I remember right, grsecurity back then said that self-compiled kernels will always be more secure than downloaded kernels due to randomizations, therefore encouraged self-compiled kernels.
Other crazy ideas: mount system map to /dev/null or other trickery (this idea is ignoring what I said above).
vsyscall=none isn’t useful as vsyscalls were removed from the kernel. kaslr isn’t useful either as Debian and most other kernels enable kaslr by default.
We can remove those too.
Shred would only help if the attacker has local access and at that point, them seeing the system map is the least of your worries.
Wouldn’t that require local access also?
It’s harder for an attacker to download the system map files from another source than to just look in /boot.
It’s much more useful for custom kernels. Even when using standard kernels, it raises the bar for more common malware. If Whonix starts using it’s own kernel, then this will become much more useful.
I don’t see any advantage to this over just deleting them. It might just cause confusion to some people as the files are there but don’t open properly.
madaidan via Whonix Forum:
We can remove those too.
We’d have to delete the kernel package from that folder which is kinda
strange?
Shred would only help if the attacker has local access and at that point, them seeing the system map is the least of your worries.
I see. The threat model for system map files wasn’t clear to me whether
to presuppose root access or not.
It’s much more useful for custom kernels. Even when using standard kernels, it raises the bar for more common malware. If Whonix starts using it’s own kernel, then this will become much more useful.
If it’s about raising the bar for common malware (off-the-shelf
malware), then kernel package deletion from /var/cache/apt/archives/
is avoidable?
I don’t see any advantage to this over just deleting them. It might just cause confusion to some people as the files are there but don’t open properly.
Advantage would be that never something readable would be written there.
Never written, never recoverable, never readable.
Ah. I didn’t realise it was the package itself.
Possibly. It may be unlikely for an attacker to look inside the package but still not that hard to do.
That would make sense. Sounds like a much better option. Another way would be to replace the file with our own null device instead of linking it to /dev/null.
It can be done with
mknod /boot/System.map c 1 3
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.
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.
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.
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.
Could you please have a look here?
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.
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?
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.