That’s weird. Are you sure all of those need to be disabled?
1 Like
madaidan via Whonix Forum:
Are you sure all of those need to be disabled?
I could have let enabled three of them or so without breaking the mount
feature. Since that seemed wrong, I disabled all of it.
1 Like
We should at least keep PrivateNetwork=true. That gets rid of all network access from the service which would reduce the chance of somebody exploiting it. Weird that Qubes is the only one breaking from this.
Ok, that works.
2 Likes
4 posts were split to a new topic: set oops=panic kernel parameter or kernel.panic_on_oops=1 sysctl for better security
What creates system-map files and can we suppress creation rather than deleting those?
We delete those but that doesn’t help much if these get created later on. Better prevent creation than “only” deleting.
1 Like
When compiling the kernel, it generates system.map files. The kernel package likely puts them into /boot so we’d have to modify the package if we want to suppress the creation of them.
They get deleted at boot by a systemd service. If they get created later on, they’d get deleted next boot.
1 Like
Which means there’s a time gap between re-creation and re-deletion which
could be abused even by chance by malware.
Could you look please if you can find the code which generates these
files? Maybe there is a config option already to disable it. And if not,
we could request it from upstream.
1 Like
The actual compilation generates them. I can’t find what places them in /boot though.
1 Like
3 posts were split to a new topic: allow loading signed kernel modules by default / disallow kernel module loading by default
Instead of trying to get rid of this time gap altogether which as far as I know, isn’t doable, we could attempt to reduce it as much as possible.
We could configure remove-system-map.service to execute our script every few minutes. This can be done by adding
Restart=always
RestartSec=5m
which would make it run every 5 minutes.
This would flood the systemd logs with “Starting remove-system-map.service” type messages though.
Alternatively, we could configure a cron job to execute our script every few minutes.
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.)
2 Likes
1 Like
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-amd64
1 Like
In 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).
1 Like
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.
1 Like
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.
1 Like