No. I ran it as root.
It wouldn’t be too hard to make it only display the logs if the user is root.
1 Like
Under the enhanced threat model of hiding as much information from user as possible, user has no business reading most of whonixcheck output. But nontrivial change since whonixcheck also used as connectivity checker / progress meter after ACW.
1 Like
Perhaps specifically those are ones that should better be hidden? If anything, hide it all for completeness sake?
1 Like
If really important errors are hidden too then users might just see a black screen and have no idea what’s happened.
E.g. a kernel panic happens for whatever reason and important errors are hidden so the user doesn’t know.
1 Like
1 Like
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 Enable the init_on_alloc=1 and init_on_free=1 Linux options (#17236) · Issues · tails / tails · GitLab 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.
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
Good point.
Here is a related bug report:
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.annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_kallsyms.ml
annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_ksyms.ml
- ^ → User should not have access to
/proc/kallsymstoo? 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?
-
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
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
Hardening/Linux - Segfault and Hardening/Linux - Segfault (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 Security - ArchWiki
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?
security-misc/debian/security-misc.postinst at master · Kicksecure/security-misc · GitHub
1 Like